CA2462701A1 - Address transition and message correlation between network nodes - Google Patents
Address transition and message correlation between network nodes Download PDFInfo
- Publication number
- CA2462701A1 CA2462701A1 CA002462701A CA2462701A CA2462701A1 CA 2462701 A1 CA2462701 A1 CA 2462701A1 CA 002462701 A CA002462701 A CA 002462701A CA 2462701 A CA2462701 A CA 2462701A CA 2462701 A1 CA2462701 A1 CA 2462701A1
- Authority
- CA
- Canada
- Prior art keywords
- network node
- address information
- message
- network
- sgsn
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W8/00—Network data management
- H04W8/26—Network addressing or numbering for mobility support
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/167—Adaptation for transition between two IP versions, e.g. between IPv4 and IPv6
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
- H04W12/80—Arrangements enabling lawful interception [LI]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W36/00—Hand-off or reselection arrangements
- H04W36/0005—Control or signalling for completing the hand-off
- H04W36/0011—Control or signalling for completing the hand-off for data sessions of end-to-end connection
- H04W36/0033—Control or signalling for completing the hand-off for data sessions of end-to-end connection with transfer of context information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W88/00—Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
- H04W88/18—Service support devices; Network management devices
- H04W88/184—Messaging devices, e.g. message centre
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/30—Network architectures or network communication protocols for network security for supporting lawful interception, monitoring or retaining of communications or communication related information
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04W—WIRELESS COMMUNICATION NETWORKS
- H04W76/00—Connection management
- H04W76/10—Connection setup
Abstract
The present invention relates to a method, system and network element for providing an address transition if a connection point at one end of a connection is changed from a first network node to a second network node of a cellular network. An address information and at least one alternative addres s information are transmitted in a signaling message from said first network node to said second network node. One of said address information and said alternative address information is selected at the second network node and used for re-establishing said connection towards the other end of said connection. Thereby, the new point of connection is allowed to re-establish the connection towards the other end of the connection, even if it can only communicate using one of the two addresses. Furthermore, signaling messages, e.g. messages relating to charging, lawful interception, and/or customized applications, received from different network nodes can be correlated based on the alternative addresses.
Description
Address Transition and Message Correlation Between Network Nodes FIELD OF THE INVENTION
The present invention relates to a method, system and network element for provid-ing an address transition, such as a transition from an IPv4 (Internet Protocol ver-y sion 4) address to an IPv6 address, between a first network node and a second network node of a cellular network, e.g. a GPRS (General Packet Radio Services) network, and/or a message correlation.
BACKGROUND OF THE INVENTION
UMTS (Universal Mobile Telecommunications System) is a more general term for the 3G (third generation) telecommunications system based on the WCDMA high capacity radio interface. GSM is the most widespread 2G (second generation) telecommunications system based on TDMA (Time Division Multiple Access) ra-dio. The goal of the GPRS system is to provide global layer 2 connectivity from a cellular mobile terminal (MT, sometimes also referred to as mobile station (MS) or user equipment (UE)) using 2G or 3G radio technology (e.g. GSM, American TDMA, UMTS, GERAN (GSM/EDGE Radio Access Network) to an external packet data network. GPRS can support various layer 3 protocols (e.g. IPv4; IPv6; PPP
(Point-to-Point Protocol)).
The main nodes of a GPRS network are SGSN (Serving GPRS Support Node) and GGSN (Gateway GPRS Support Node). SGSNs are the nodes serving the MT. Each SGSN supports GPRS for GSM and/or UMTS. GGSNs are the node handling the interworking with PDNs (Packet Data Networks). Signaling and data are exchanged between SGSN and GGSN or SGSN and SGSN using the GTP
(GPRS Tunneling Protocol) protocol. GTP protocol handles mobility, and creation, modification and deletion of GTP tunnels, as well as transfer of user data between GSNs. GTP allows multi-protocol packets to be tunneled between GSNs and be-tween an SGSN and the UMTS Terrestrial Radio Access Network (UTRAN, not shown) through which a connection to the concerned MT is established. Other systems components need not be aware of the GTP. Typically, two IP addresses are used for a single tunnel, one for the GTP control message (i.e. signaling) and one for the GTP user packet (i.e. carrying user data).
At GPRS attach, the SGSN establishes a mobility management (MM) context containing information pertaining to e.g. mobility and security for the concerned MT. At PDP context activation, the SGSN establishes a PDP context, to be used for routing purposes, with the GGSN the subscriber will be using.A GPRS
attached mobile terminal (MT) can be assigned either a static or dynamic IP address (re-ferred to also as PDP address). The static address is assigned by the Home Pub-lic Land Mobile Network (HPLMN) operator at the time of subscription. The dy-namic IP address can be allocated by a GGSN (Gateway GPRS Support Node) of either the HPLMN or the visited PLMN (VPLMN) operator at PDP (Packet Date Protocol) context activation time. In addition to address allocation, the GGSN
im-plements the forwarding of IP packets from a GTP (GPRS Tunneling Protocol) tunnel to a packet data network (PDN) and vice versa. There are two kinds of PLMN backbone networks, an Intra-PLMN backbone network and an Inter-PLMN
backbone network. The Intra-PLMN backbone network is a private IP network in-tended for packet domain data and signalling within a PLMN only, while the Inter-PLMN backbone is used for roaming from one PLMN to another (via Border Gate-ways). Serving GPRS Support Nodes (SGSNs) and GGSNs use the Intra-PLMN
backbone to exchange GPRS domain data and signalling.
During roaming, both the Intra-PLMN backbone of the home and visited networks are used in addition to the Inter-PLMN backbone. When a subscriber is roaming to another PLMN, i.e. a VPLMN, the user needs to first attach to the network. In GPRS attach, the MT informs the Serving SGSN of its intention to connect to the network by giving information about its identity, capability and location. The SGSN
then checks the MT's identity and performs an authentication procedure in order to secure the transmission path. The attachment is completed after the SGSN has received roaming subscriber data from the Home Location Register (HLR) of the subscriber's HPLMN and finished a location update procedure. After the GPRS
attach, the MT sends an 'Activate PDP context' request, in Which the Access Point Name (APN) is a reference to the GGSN Access Point (AP) to be used in either the home or visited PLMN. The SGSN selects the GGSN based on a PDP context subscription record and sends the context data to a selected GGSN. The GGSN
then routes the packets to the appropriate Packet Data Networks (PDN).
When a subscriber is roaming in the VPLMN, there are the following two possibili-ties for GGSN selection. Firstly, the home network GGSN can be used via the In-ter-PLMN backbone and BGs. The home GGSN then routes the packets to their destination. Secondly, a visited domain GGSN can be used for routing the packets from the VPLMN to their destination directly through a packet data network (PDN), such as the public Internet.
It should be noted that there are two levels of IP addressing:
- the user IP address corresponding to the packets carried over GTP proto-col. The corresponding IP address is referred to as PDP address or user address; and - the network IP address corresponding to the packets carried below GTP
protocol. The corresponding IP addresses are the node IP addresses used to exchange GTP packets between GSNs. These IP addresses might also be used for network operation such as charging or O&M.
User and network addresses are independent of each other thanks to the GTP
protocol, and could both be either IPv4 or IPv6.
The GPRS backbone nodes of the second (2G) and third (3G) generation may optionally use an IPv6 based addressing for network addresses. However, existing specifications allowing the use of IPv6 addresses, do not define how to maintain backward compatibility with IPv4 based nodes. An SGSN should know in advance that the GGSN selected supports IPv6 addresses before inserting an IPv6 address e.g. in a create PDP context request message.
Furthermore, another problem arises with the known procedures. If a MT moves from an IPv6 capable SGSN connected to an IPv6 capable GGSN to an IPv4 only SGSN, the communication wilt get lost as the new SGSN cannot use the IPv6 ad-dress transferred. Such a scenario is very realistic in particular when two operators with equipment from different manufacturers (or just different software release) have roaming agreements (e.g. national roaming). It should be noted that existing IPv4-to-IPv6 transition mechanisms do not apply here as they do not affect IP
ad-dresses carried in GTP.
In addition, a practical requirement is that the protocol changes have to be done so that nodes based on older version of specifications (and so not supporting en-hancement proposed here), have to continue intenworking with new nodes sup-porting the proposed enhancement proposed here.
SUMMARY OF THE INVENTION
It is therefore an object of the present invention to provide a method and system for providing an address transition or correlation function, by means of which backward address compatibility can be achieved.
This object is achieved by a method and system as claimed in claims 1, 13, 17 and 19, respectively.
Additionally, the above object is achieved by a network node as claimed in claims 23, 27 and 30, respectively.
Accordingly, if one of the point of connection is changed (e.g. Inter SGSN
Routing area update; Serving RNC relocation), the old point of connection (e.g. old SGSN) shall send to the new point of connection (e.g. new SGSN) both first and second address, in order to allow the new point of connection to re-establish the connec-tion towards the other end of the connection (GGSN), even if it can only communi-cate using one of the 2 addresses.
Furthermore, signaling messages, e.g. messages relating to charging, lawful inter-ception, and/or customized applications (e.g. Customized Applications for Mobile network Enhanced Logik (CAMEL) architecture), received from different network nodes can be correlated based on the alternative addresses.
Advantageous further developments are defined in the dependent claims.
The present invention relates to a method, system and network element for provid-ing an address transition, such as a transition from an IPv4 (Internet Protocol ver-y sion 4) address to an IPv6 address, between a first network node and a second network node of a cellular network, e.g. a GPRS (General Packet Radio Services) network, and/or a message correlation.
BACKGROUND OF THE INVENTION
UMTS (Universal Mobile Telecommunications System) is a more general term for the 3G (third generation) telecommunications system based on the WCDMA high capacity radio interface. GSM is the most widespread 2G (second generation) telecommunications system based on TDMA (Time Division Multiple Access) ra-dio. The goal of the GPRS system is to provide global layer 2 connectivity from a cellular mobile terminal (MT, sometimes also referred to as mobile station (MS) or user equipment (UE)) using 2G or 3G radio technology (e.g. GSM, American TDMA, UMTS, GERAN (GSM/EDGE Radio Access Network) to an external packet data network. GPRS can support various layer 3 protocols (e.g. IPv4; IPv6; PPP
(Point-to-Point Protocol)).
The main nodes of a GPRS network are SGSN (Serving GPRS Support Node) and GGSN (Gateway GPRS Support Node). SGSNs are the nodes serving the MT. Each SGSN supports GPRS for GSM and/or UMTS. GGSNs are the node handling the interworking with PDNs (Packet Data Networks). Signaling and data are exchanged between SGSN and GGSN or SGSN and SGSN using the GTP
(GPRS Tunneling Protocol) protocol. GTP protocol handles mobility, and creation, modification and deletion of GTP tunnels, as well as transfer of user data between GSNs. GTP allows multi-protocol packets to be tunneled between GSNs and be-tween an SGSN and the UMTS Terrestrial Radio Access Network (UTRAN, not shown) through which a connection to the concerned MT is established. Other systems components need not be aware of the GTP. Typically, two IP addresses are used for a single tunnel, one for the GTP control message (i.e. signaling) and one for the GTP user packet (i.e. carrying user data).
At GPRS attach, the SGSN establishes a mobility management (MM) context containing information pertaining to e.g. mobility and security for the concerned MT. At PDP context activation, the SGSN establishes a PDP context, to be used for routing purposes, with the GGSN the subscriber will be using.A GPRS
attached mobile terminal (MT) can be assigned either a static or dynamic IP address (re-ferred to also as PDP address). The static address is assigned by the Home Pub-lic Land Mobile Network (HPLMN) operator at the time of subscription. The dy-namic IP address can be allocated by a GGSN (Gateway GPRS Support Node) of either the HPLMN or the visited PLMN (VPLMN) operator at PDP (Packet Date Protocol) context activation time. In addition to address allocation, the GGSN
im-plements the forwarding of IP packets from a GTP (GPRS Tunneling Protocol) tunnel to a packet data network (PDN) and vice versa. There are two kinds of PLMN backbone networks, an Intra-PLMN backbone network and an Inter-PLMN
backbone network. The Intra-PLMN backbone network is a private IP network in-tended for packet domain data and signalling within a PLMN only, while the Inter-PLMN backbone is used for roaming from one PLMN to another (via Border Gate-ways). Serving GPRS Support Nodes (SGSNs) and GGSNs use the Intra-PLMN
backbone to exchange GPRS domain data and signalling.
During roaming, both the Intra-PLMN backbone of the home and visited networks are used in addition to the Inter-PLMN backbone. When a subscriber is roaming to another PLMN, i.e. a VPLMN, the user needs to first attach to the network. In GPRS attach, the MT informs the Serving SGSN of its intention to connect to the network by giving information about its identity, capability and location. The SGSN
then checks the MT's identity and performs an authentication procedure in order to secure the transmission path. The attachment is completed after the SGSN has received roaming subscriber data from the Home Location Register (HLR) of the subscriber's HPLMN and finished a location update procedure. After the GPRS
attach, the MT sends an 'Activate PDP context' request, in Which the Access Point Name (APN) is a reference to the GGSN Access Point (AP) to be used in either the home or visited PLMN. The SGSN selects the GGSN based on a PDP context subscription record and sends the context data to a selected GGSN. The GGSN
then routes the packets to the appropriate Packet Data Networks (PDN).
When a subscriber is roaming in the VPLMN, there are the following two possibili-ties for GGSN selection. Firstly, the home network GGSN can be used via the In-ter-PLMN backbone and BGs. The home GGSN then routes the packets to their destination. Secondly, a visited domain GGSN can be used for routing the packets from the VPLMN to their destination directly through a packet data network (PDN), such as the public Internet.
It should be noted that there are two levels of IP addressing:
- the user IP address corresponding to the packets carried over GTP proto-col. The corresponding IP address is referred to as PDP address or user address; and - the network IP address corresponding to the packets carried below GTP
protocol. The corresponding IP addresses are the node IP addresses used to exchange GTP packets between GSNs. These IP addresses might also be used for network operation such as charging or O&M.
User and network addresses are independent of each other thanks to the GTP
protocol, and could both be either IPv4 or IPv6.
The GPRS backbone nodes of the second (2G) and third (3G) generation may optionally use an IPv6 based addressing for network addresses. However, existing specifications allowing the use of IPv6 addresses, do not define how to maintain backward compatibility with IPv4 based nodes. An SGSN should know in advance that the GGSN selected supports IPv6 addresses before inserting an IPv6 address e.g. in a create PDP context request message.
Furthermore, another problem arises with the known procedures. If a MT moves from an IPv6 capable SGSN connected to an IPv6 capable GGSN to an IPv4 only SGSN, the communication wilt get lost as the new SGSN cannot use the IPv6 ad-dress transferred. Such a scenario is very realistic in particular when two operators with equipment from different manufacturers (or just different software release) have roaming agreements (e.g. national roaming). It should be noted that existing IPv4-to-IPv6 transition mechanisms do not apply here as they do not affect IP
ad-dresses carried in GTP.
In addition, a practical requirement is that the protocol changes have to be done so that nodes based on older version of specifications (and so not supporting en-hancement proposed here), have to continue intenworking with new nodes sup-porting the proposed enhancement proposed here.
SUMMARY OF THE INVENTION
It is therefore an object of the present invention to provide a method and system for providing an address transition or correlation function, by means of which backward address compatibility can be achieved.
This object is achieved by a method and system as claimed in claims 1, 13, 17 and 19, respectively.
Additionally, the above object is achieved by a network node as claimed in claims 23, 27 and 30, respectively.
Accordingly, if one of the point of connection is changed (e.g. Inter SGSN
Routing area update; Serving RNC relocation), the old point of connection (e.g. old SGSN) shall send to the new point of connection (e.g. new SGSN) both first and second address, in order to allow the new point of connection to re-establish the connec-tion towards the other end of the connection (GGSN), even if it can only communi-cate using one of the 2 addresses.
Furthermore, signaling messages, e.g. messages relating to charging, lawful inter-ception, and/or customized applications (e.g. Customized Applications for Mobile network Enhanced Logik (CAMEL) architecture), received from different network nodes can be correlated based on the alternative addresses.
Advantageous further developments are defined in the dependent claims.
BRIEF DESCRIPTION OF THE DRAWINGS
In the following, the present invention will be described in greater detail based on a preferred embodiment with reference to the accompanying drawings, in which:
Fig. 1 shows a schematic block diagram of a GPRS backbone network architec-ture, in which the present invention can be implemented;
Fig. 2 shows a signaling diagram indicating indicating an Inter-SGSN routing area update procedure according to the preferred embodiment, and Fig. 3 shows a signaling diagram indicating a Serving SRNS Relocation procedure according to the preferred embodiment.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
The preferred embodiment will now be described based on a packet domain PLMN backbone network architecture as indicated in Fig. 1, in which an IPv6 to IPv4 address transition mechanism is used.
According to Fig. 1, a packet data network (PDN) 10 (e.g. an IP network) is con-nected via a first GGSN 31 to a first PLMN 71 comprising a first Intra-PLMN
back-bone network 51. Furthermore, the first PLMN 71 includes at least a first SGSN
and a second SGSN 62 connected to each other and to the first GGSN 31 through the first Intra-PLMN backbone network 51. Additionally, the PDN 10 is connected to each other via a second GGSN 32 to a second PLMN 72 comprising a second Intra-PLMN backbone network 52. Furthermore, the second PLMN 72 includes at least a third SGSN 63 connected to the second GGSN 32 through the second In-tra-PLMN backbone network 52. The first and second PLMNs 71, 71 are con-nected to each other via an Inter-PLMN backbone network 20. The connection between the first PLMN 71 and the Inter-PLMN backbone network 20 is provided through a first border gateway (BG) 41. Similarly, the connection between the sec-ond PLMN 72 and the Inter-PLMN backbone network 20 is provided through a second BG 42.
Each of the Intra-PLMN backbone networks 51, 52 may be a private IP network intended for packet domain data and signaling. A private IP network is an IP
net-work to which some access control mechanism is applied in order to achieve a required level of security. The Inter-PLMN backbone network 20 can be packet data network, e.g. the public Internet or a leased line, which may be selected by a roaming agreement including a BG security functionality (i.e. typically just a router with security functions). The first and second BGs 41, 42 are not defined within the scope of the packet domain.
The GPRS Support Nodes (GSNs), i.e. the first to third SGSNs 61 to 63 and the first and second GGSNs 31, 32, contain functionality required to support GPRS
functionality for GSM (Global System for Mobile communication) and/or UMTS. In particular, the first and second GGSNs 31, 31 represent network nodes which are accessed by the PDN 10 due to evaluation of the PDP address. It contains routing information for GPRSattached users. The routing information is used to tunnel packet data units (PDUs) to the MT's current point of attachment, i.e. the respec-tive Serving SGSN. Thus, the first and second GGSNs 31, 32 are the first point of PDN interconnection with the first and second PLMNs 71, 72, respectively. The first to third SGSNs 61 to 63 represent nodes for serving the MT. Each SGSN
supports GPRS for GSM and/or UMTS.
Further details regarding the network architecture and signaling procedures can be gathered from the 3GPP (3rd Generation Partnership Project) specification TS
23.060 Release 4.
According to the preferred embodiment, an SGSN willing to use an IPv6 address-ing will always indicate IPv6 and also IPv4 SGSN addresses in a respective GTP
signaling message used to request creation of a GTP tunnel to the selected GGSN. Optionally, the SGSN may also indicate IPv6 and also IPv4 SGSN ad-dresses in a respective GTP signaling message used to request update of a GTP
tunnel. But this is not necessary if before sending the update, the SGSN
already knows the type of addresses supported by GGSN. It may however be useful if the operator like to configure on a node by node basis the technology to be used (may be due to intermediate network).
If the selected GGSN supports IPv6 in the network plane, it shall also indicate IPv6 addresses in the corresponding GTP response message together with IPv4 ad-dresses. The IPv4 addresses are stored in the SGSN and not used for transmis-sion. IPv6 addresses are used for transmission on the network plane. In case of an inter SGSN handover, IPv4 and IPv6 addresses shall be given to the new SGSN in a backward compatible way. If the new SGSN does not support IPv6 ad-dresses, it uses the obtained IPv4 addresses to update the tunnel towards the GGSN. Also the GGSN may start receiving user data from the new SGSN before the tunnel has been updated. Therefore the first and second GGSNs 31, 32 shall be ready to receive GTP packets (signaling or user data) on either IPv4 or IPv6 addresses.
It should be noted, that in future a new SGSN may be provided, which is capable of using only IPv6 on network plane, and same principles would apply.
As an implementation alternative, the node could select the transmission technol-ogy (IPv4 or IPv6) to be used based on operator configuration If the selected GGSN does not support IPv6 in the network plane, it indicates only IPv4 addresses in the corresponding GTP response message. IPv4 addresses are then used for transmission on the network plane as currently defined.
Because it is proposed to send the IPv6 address as a new optional information element, backward compatibility can be provided so as to introduce IPv6 in future network nodes and maintain connections on the network plan even if a new SGSN
supports only IPv4.
In the following, examples for specific signaling messages and the incorporation of a specific address field for transmitting an alternative address will be described with reference to Figs. 2 and 3. Specific details regarding the signaling messages and procedures can be gathered from the 3GPP specifications TS 29.060 and TS
23.060 Release 4.
A Create PDP Context Request is sent from a SGSN node to a GGSN node as a part of the GPRS PDP Context Activation procedure. A valid request initiates the creation of a tunnel between a PDP Context in a SGSN and a PDP Context in a GGSN. If the SGSN prefers to use IPv6 below GTP, it include the IPv6 addresses in new message fields Alternative SGSN Address, and an alternative or equivalent IPv4 address in existing message fields SGSN address. If the GGSN supports IPv6 below GTP, it stores and uses the alternative IPv6 SGSN addresses for communication with the SGSN. If the GGSN supports only IPv4 below GTP, it stores and uses the IPv4 SGSN addresses for communication with the SGSN. The _$_ SGSN accepts packets whether they are sent to its IPv4 or IPv6 address. The GGSN should not store SGSN IP addresses that it does not use. This mechanism provides maximum flexibility, as it is not based on special DNS features, and al-lows the GGSN to have processes using IPv4 only and processes using both IPv4 and IPv6.
The following Table 1 shows the specific information elements provided in the Create PDP Context Request message.
_g_ Table 1:
Information element Presence require-ment IMSI Conditional Recovery Optional Selection mode Conditional Tunnel Endpoint Identifier DataMandatory Tunnel Endpoint Identifier ControlConditional Plane NSAPI Mandatory Linked NSAPI Conditional Charging Characteristics Optional Trace Reference Optional Trace Type Optional End User Address Conditional Access Point Name Conditional Protocol Configuration Options Conditional SGSN Address for signalling Mandatory SGSN Address for user traffic Mandatory Alternative SGSN Address for Optional signalling Alternative SGSN Address for Optional user traffic MSISDN Conditional Quality of Service Profile Mandatory TFT Conditional Trigger Id Optional OMC Identity Optional Private Extension Optional The Create PDP Context Response message is sent from the GGSN node to the SGSN node as a response of a Create PDP Context Request. When the SGSN
receives the Create PDP Context Response with the Cause value indicating 'Re-quest Accepted', the SGSN activates the PDP context and may start to forward PDUs to/from the MT from/to the external data network.
If the GGSN supports IPv6 below GTP, and the SGSN included an IPv6 SGSN
address in the request, the GGSN shall include the IPv6 addresses in the new fields Alternative GGSN Address, and an equivalent IPv4 address in the fields GGSN address. The SGSN uses the alternative IPv6 GGSN addresses for com-munication with the GGSN, except if the operator has configured the use of IPv4.
The SGSN stores the GGSN addresses and sends them to a new SGSN in a PDP
context response message (message sent by old SGSN to new SGSN, after an MS has performed a Routing area update procedure to a new SGSN, that the new SGSN has sent a PDP context request message to the old SGSN). The GGSN
shall accept packets whether they are sent to its IPv4 or IPv6 address. This mechanism avoids losing connection if the new SGSN support IPv4 only below GTP.
Table 2 shows specific information elements provided in the Create PDP Context Response message.
Table 2:
Information element Presence requirement Cause Mandatory Reordering required Conditional Recovery Optional Tunnel Endpoint Identifier Data Conditional Tunnel Endpoint Identifier Control Conditional Plane Charging ID Conditional End User Address Conditional Protocol Configuration Options Optional GGSN Address for Control Plane Conditional GGSN Address for user traffic Conditional Alternative GGSN Address for ControlConditional Plane Alternative GGSN Address for user Conditional traffic Quality of Service Profile Conditional Charging Gateway Address Optional Private Extension Optional Furthermore, an Update PDP Context Request message is sent from a SGSN to a GGSN as part of the GPRS Inter SGSN Routing Update procedure or the PDP
Context Modification procedure or to redistribute contexts due to load sharing.
The SGSN may use SGSN IPv6 addresses only if it has received an IPv6 GGSN
address from an old SGSN (Inter SGSN Routing Area Update case) or GGSN
(PDP context modification). Otherwise SGSN uses SGSN IPv4 addresses.
If the GGSN supports IPv6 below GTP, and the SGSN included an IPv6 SGSN
address in the request, the GGSN includes the IPv6 addresses in the fields Alter-native GGSN Address, and an equivalent IPv4 address in the fields GGSN ad-dress. The SGSN uses the alternative IPv6 GGSN addresses for communication with the GGSN. The SGSN may store both IPv4 and IPv6 GGSN addresses and send them to a new SGSN in PDP context response message. The GGSN
alternative address fields are not sent if the GGSN address field is not sent.
This mechanism guarantees that the SGSN always stores proper IPv4 and IPv6 GGSN
addresses, so that connection will not be lost if moving to a new SGSN
supporting only IPv4 below GTP.
In the following Table 3, specific information elements in the Update PDP
Context Response message are shown.
Table 3:
Information element Presence require-ment Cause Mandatory Recovery Optional Tunnel Endpoint Identifier Data Conditional Tunnel Endpoint Identifier ControlConditional Plane Charging ID Conditional GGSN Address for Control Plane Conditional GGSN Address for User Traffic Conditional Alternative GGSN Address for ControlConditional Plane Alternative GGSN Address for user Conditional traffic Quality of Service Profile Conditional Charging Gateway Address Optional Private Extension Optional Furthermore, as regards the SGSN Context Request message, the new SGSN
sends this message to the old SGSN to get the mobility management (MM) and PDP Contexts for the MT. The old SGSN responds with an SGSN Context Re-sponse.
The new SGSN adds an SGSN Address for the control plane. If the new SGSN
supports IPv6 below GTP, it adds its IPv6 address in the field Alternative SGSN
Address for Control Plane. The old SGSN then selects the SGSN address for Con-trot Plane depending on its IPv6 supports, and stores this selected SGSN
Address and uses it when sending control plane messages for the MT to the new SGSN in the SGSN context transfer procedure.
Table 4 shows specific information elements provided in the SGSN Context Re-quest message.
Table 4:
Information element Presence require-ment IMSI Conditional Routing Area Identity (RAI) Mandatory Temporary Logical Link IdentifierConditional (TLLI) Packet TMSI (P-TMSI) Conditional P-TMSI Signature Conditional MS Validated Optional Tunnel Endpoint Identifier ControlMandatory Plane SGSN Address for Control Plane Mandatory Alternative SGSN Address for Conditional Control Plane Private Extension Optional The old SGSN sends an SGSN Context Response message to the new SGSN as a response to a previous SGSN Context Request. The old SGSN may use SGSN
IPv6 addresses only if it received IPv6 SGSN address from the new SGSN. Oth-erwise SGSN shall use SGSN IPv4 addresses.
The new SGSN sends an SGSN Context Acknowledge message to the old SGSN
as a response to the SGSN Context Response message. Only after receiving the SGSN Context Acknowledge message, the old SGSN starts to forward user data packets. SGSN Context Acknowledge indicates to the old SGSN that the new SGSN has correctly received PDP Context information and is ready to receive user data packets.
The new SGSN uses an SGSN Address for user traffic, which may differ from that provided by the underlying network service (e.g. IP). The old SGSN stores this SGSN Address and uses it when sending downlink PDUs to the new SGSN for the MT. The SGSN may use IPv6 addresses only if it received IPv6 SGSN address for control plane from the old SGSN. Otherwise the SGSN use SGSN IPv4 ad-dresses.
Fig. 2 shows a signaling diagram indicating an Inter-SGSN routing area update procedure according to the preferred embodiment.
In this signaling example, the MT sends a Routing Area Update Request to a new SGSN, so as to initiate a routing area update. In response thereto, the new SGSN
sends an SGSN Context Request message including the SGSN Address fields and the Alternative SGSN Address fields to the old SGSN. In response thereto, the old SGSN returns an SGSN Context Response message in which the desired address type is set in the SGSN Address for Control Plane fields, and all GGSN
IPv4 and IPv6 addresses are included if available. The new SGSN responds with an SGSN Context Acknowledge message including the used address type infor-oration. Then, the new SGSN sends an Update PDP Context Request message including the set address type information to the respective GGSN. This message is sent using a GGSN IP address received from old SGSN. If the new SGSN and GGSN support IPv6 on the network plane, the IPv6 address of GGSN is preferably used. If either SGSN or GGSN does not support IPv6, IPv4 addresses are used.
Here, it is assumed that in a first phase of transition towards IPv6, all nodes sup-port IPv4. The GGSN returns an Update PDP Context Response message includ-ing the GGSN Address fields and the Alternative GGSN Address fields. These ad-dress fields are especially necessary in the following cases:
- The old SGSN supported only IPv4, and had not stored the alternative GGSN address, so that the new SGSN needs to receive it from GGSN to be able to use IPv6 for the connection - The GGSN has changed its IP address (typically due to a reallocation of the PDP context to a new processing card) In addition, if for some reason, the GGSN is configured to use IPv4 to communi-cate towards the new SGSN (due to possible problem in intermediate IP
network), the GGSN will return only the IPv4 addresses and will not send an alternative ad-dress field containing the IPv6 address.
Finally, the required routing area update procedure is performed.
As a further GTP signalling message, a Forward Relocation Request message is defined, which is sent by an old SGSN to a new SGSN to convey necessary in-formation to perform an SRNS (Serving Radio Network Subsystem) relocation procedure between the new SGSN and a target RNC (Radio Network Controller) of the UTRAN. In this case, the old SGSN adds an SGSN Address for Control Plane field information. If the old SGSN supports IPv6 below GTP, it adds its IPv6 address in this field Alternative SGSN Address for Control Plane. The new SGSN
selects the SGSN address for Control Plane depending on its IPv6 supports, and stores this selected SGSN address and uses it when sending control plane mes-sages for the MT to the old SGSN in the SRNS relocation procedure.
Table 5 shows specific information elements provided in the Forward Relocation Request message.
Table 5:
Information element Presence requirement IMSI Mandatory Tunnel Endpoint Identifier ControlMandatory Plane RANAP Cause Mandatory MM Context Mandatory PDP Context Conditional SGSN Address for Control plane Mandatory Alternative SGSN Address for ControlOptional plane Target Identification Mandatory UTRAN transparent container Mandatory Private Extension Optional The new SGSN sends a Forward Relocation Response message to the old SGSN
as a response to a previous Forward Relocation Request message. The new SGSN adds an SGSN Address for Control Plane information. The SGSN may insert IPv6 addresses only if it received an IPv6 SGSN address for control plane from the old SGSN. Otherwise the new SGSN uses SGSN IPv4 addresses. The old SGSN stores this SGSN address and uses it when sending control plane mes-sages for the MT to the new SGSN in the SRNS relocation procedure.
Fig. 3 shows a signaling diagram indicating an SRNS (Serving Radio Network Subsystem) relocation procedure according to the preferred embodiment.
In this signaling example, a source SRNS of the UTRAN decides to perform or initiate an SRNS relocation and sends a Relocation Required message to the old SGSN. In response thereto, the old SGSN determines if the SRNS relocation is an inter-SGSN SRNS relocation and, if so, it sends a Forward Relocation Request message including the SGSN Address field and the Alternative SGSN Address field for control plane signaling to the respective new SGSN. In response thereto, the new SGSN send a Relocation Request message to the target Radio Network Controller (RNC) of the UTRAN. Then, the lu bearers of the radio access bearers (RABs) are setup between the target RNC and the new SGSN as the existing ra-dio bearers will be reallocated between the MT and the target RNC when the tar-get RNC takes the role of the Serving RNC in the new SRNS. After the new SGSN
has received the Relocation Request Acknowledgement message from the UTRAN, the GTP tunnels are established between the target RNC and the new SGSN. Then, the Forward Relocation Response message is sent from the new SGSN to the old SGSN to thereby indicate that the target RNC is ready to receive from the source SRNC (Serving RNC) of the SRNS the forwarded packet data units (PDUs). The old SGSN continues the SRNS relocation by sending a Reloca-tion Command message to the source SRNC. The source SRNC is now ready to forward downlink user data directly to the target RNC. When the data forwarding is completed, the target RNC send a relocation Detect message to the new SGSN.
In response thereto, the new SGSN sends an Update PDP Context Request mes-sage to a concerned GGSN. The GGSN returns an Update PDP Context Re-spouse message including the GGSN Address fields and the Alternative GGSN
Address fields. When the new SGSN receives a Relocation Complete message from the SRNC, a Forward Relocation Complete signaling is exchanged between the new and the old SGSNs , and then the old SGSN initiates an lu release proce-dure at the SRNC. Finally, if the new Routing Area Identification is different, the MT initiates a Routing Area Update procedure.
Furthermore, a PDP Context information element contains the Session Manage-ment parameters, defined for an external packet data network address, that are necessary to transfer between SGSNs at the Inter SGSN Routing Area Update procedure.
If the GGSN negotiated the use of IPv6 below GTP with the old SGSN, the old SGSN sets Alternative GGSN Address for User Traffic and Alternative GGSN Ad-dress for Control Plane fields to contain the IPv6 addresses to be used to commu-nicate with the GGSN. A new SGSN not supporting IPv6 below GTP ignores these alternative GGSN addresses, and uses for communication the GGSN Address for User Traffic and GGSN Address for Control Plane fields. A new SGSN supporting IPv6 below GTP stores the GGSN Address for User Traffic and GGSN Address for Control Plane, but uses use for communication the Alternative GGSN Address for User Traffic and Alternative GGSN Address for Control Plane.
In Table 6, a PDP Context information field is shown.
Table 6 1 Type =
(Decimal) 2-3 Length 4 Res-VAA Res-OrderNSAPI
erved erved X X X X SAPI
6 QoS
Sub Length 7 - QoS
(q+6) Sub [4..255]
Q+7 QoS
Req Length (q+8)-(2q+7)QoS
Req [4..255]
2q+8 QoS
Neg.
Length (2q+9~(3q+8)QoS
Neg [4..255]
(3q+9)-(3q+10)Sequence Number Down (SND) (3q+11 Sequence )- Number (3q+12)Up (SNU) '' 3q+13 Send N-PDU
Number 3q+14 Receive N-PDU
Number (3q+15)-Uplink (3q+18)Tunnel Endpoint Identifier Control Plane (3q+19)-UpIinkTunnel (3q+22)Endpoint Identifier Data I
3q+23 PDP
Context Identifier 3q+24 Spare PDP Type Organisation 3q+25 PDP
Type Number 3q+26 PDP
Address Length (3q+27)-mPDP
Address [1..63]
M+1 GGSN
Address for control plane Length (m+2)-nGGSN
Address for control plane [4..16]
N+1 GGSN
Address for User Traffic Length (n+2)-oGGSN
Address for User Traffic [4..16]
O+1 APN
length (o+2)-pAPN
P+1 Spare Transaction Identifier (sent as 0) P+2 Transaction Identifier Alternative GGSN
Address for control plane Length Alternative GGSN
Address for control plane [4..16]
Alternative GGSN
Address for User Traffic Length Alternative GGSN
Address for User Traffic [4..16]
If having either IPv6 or IPv4 address in GGSN Address for Control Plane is al-lowed, GGSN Address for Control Plane of the PDP context information field may sometimes be an IPv6 address and sometimes an IPv4 address during an active PDP context. This may happen e.g. if GGSN indicates IPv6 address in GGSN Ad-dress for Control Plane and IPv4 address in Alternative GGSN Address for Control Plane at PDP context activation, whereas an old SGSN indicates IPv4 address in GGSN Address for Control Plane to a new SGSN at routing area update. In this case, GGSN Address for Control Plane is the same in GGSN and old SGSN, whereas GGSN Address for Control Plane is different in new SGSN. In this case, e.g. charging correlation by using GGSN Address for Control Plane does not work.
According to the preferred embodiment, a GGSN supporting both IPv6 and IPv4 adds both IPv6 address and IPv4 address to CDRs (Call Detailed Records) cre-ated for a PDP context, i.e. to G-CDRs. The SGSN may add either one IP ad-dress, i.e. GGSN Address for Control Plane, or two IP addresses, i.e. GGSN Ad-dress for Control Plane and Alternative GGSN Address for Control Plane, to the CDRs created for the PDP context, i.e. to S-CDRs. This way, it is possible for the CGF (Charging Gateway Functionality) to correlate CDRs created by the GGSN
(including both IPv6 address and IPv4 address) and CDRs created by the SGSN(s) (including either one IP address, IPv6 or IPv4, or including both IPv6 ad-dress and IPv4 address).
In addition to charging, correlation may be~ needed e.g. for lawful interception or CAMEL messages or information. In general, any message or information gener-ated by multiple nodes can be correlated based on the address and alternative address information. For lawful interception correlation, GGSN sends both IPv6 address and IPv4 address, whereas SGSN may send either one IP address, i.e.
GGSN Address for Control Plane, or two IP addresses, i.e. GGSN Address for Control Plane and Alternative GGSN Address for Control Plane. GGSN thus sends both IPv6 address and IPv4 address, whereas SGSN may send either IPv6 ad-dress or IPv4 address or both for lawful interception correlation. This way, it is possible to correlate e.g. lawful interception information created by GGSN for the PDP context and lawful interception information created by SGSN(s) for the PDP
context.
It is noted that the present invention can be implemented in any cellular network to provide address backward compatibility or message correlation function, when an address information is transferred between network nodes. The names of the vari-ous functional entities, signaling messages and information elements used in the context of the preferred embodiment are not intended to limit or restrict the inven-tion. The preferred embodiments may thus vary within the scope of the attached claims.
In the following, the present invention will be described in greater detail based on a preferred embodiment with reference to the accompanying drawings, in which:
Fig. 1 shows a schematic block diagram of a GPRS backbone network architec-ture, in which the present invention can be implemented;
Fig. 2 shows a signaling diagram indicating indicating an Inter-SGSN routing area update procedure according to the preferred embodiment, and Fig. 3 shows a signaling diagram indicating a Serving SRNS Relocation procedure according to the preferred embodiment.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
The preferred embodiment will now be described based on a packet domain PLMN backbone network architecture as indicated in Fig. 1, in which an IPv6 to IPv4 address transition mechanism is used.
According to Fig. 1, a packet data network (PDN) 10 (e.g. an IP network) is con-nected via a first GGSN 31 to a first PLMN 71 comprising a first Intra-PLMN
back-bone network 51. Furthermore, the first PLMN 71 includes at least a first SGSN
and a second SGSN 62 connected to each other and to the first GGSN 31 through the first Intra-PLMN backbone network 51. Additionally, the PDN 10 is connected to each other via a second GGSN 32 to a second PLMN 72 comprising a second Intra-PLMN backbone network 52. Furthermore, the second PLMN 72 includes at least a third SGSN 63 connected to the second GGSN 32 through the second In-tra-PLMN backbone network 52. The first and second PLMNs 71, 71 are con-nected to each other via an Inter-PLMN backbone network 20. The connection between the first PLMN 71 and the Inter-PLMN backbone network 20 is provided through a first border gateway (BG) 41. Similarly, the connection between the sec-ond PLMN 72 and the Inter-PLMN backbone network 20 is provided through a second BG 42.
Each of the Intra-PLMN backbone networks 51, 52 may be a private IP network intended for packet domain data and signaling. A private IP network is an IP
net-work to which some access control mechanism is applied in order to achieve a required level of security. The Inter-PLMN backbone network 20 can be packet data network, e.g. the public Internet or a leased line, which may be selected by a roaming agreement including a BG security functionality (i.e. typically just a router with security functions). The first and second BGs 41, 42 are not defined within the scope of the packet domain.
The GPRS Support Nodes (GSNs), i.e. the first to third SGSNs 61 to 63 and the first and second GGSNs 31, 32, contain functionality required to support GPRS
functionality for GSM (Global System for Mobile communication) and/or UMTS. In particular, the first and second GGSNs 31, 31 represent network nodes which are accessed by the PDN 10 due to evaluation of the PDP address. It contains routing information for GPRSattached users. The routing information is used to tunnel packet data units (PDUs) to the MT's current point of attachment, i.e. the respec-tive Serving SGSN. Thus, the first and second GGSNs 31, 32 are the first point of PDN interconnection with the first and second PLMNs 71, 72, respectively. The first to third SGSNs 61 to 63 represent nodes for serving the MT. Each SGSN
supports GPRS for GSM and/or UMTS.
Further details regarding the network architecture and signaling procedures can be gathered from the 3GPP (3rd Generation Partnership Project) specification TS
23.060 Release 4.
According to the preferred embodiment, an SGSN willing to use an IPv6 address-ing will always indicate IPv6 and also IPv4 SGSN addresses in a respective GTP
signaling message used to request creation of a GTP tunnel to the selected GGSN. Optionally, the SGSN may also indicate IPv6 and also IPv4 SGSN ad-dresses in a respective GTP signaling message used to request update of a GTP
tunnel. But this is not necessary if before sending the update, the SGSN
already knows the type of addresses supported by GGSN. It may however be useful if the operator like to configure on a node by node basis the technology to be used (may be due to intermediate network).
If the selected GGSN supports IPv6 in the network plane, it shall also indicate IPv6 addresses in the corresponding GTP response message together with IPv4 ad-dresses. The IPv4 addresses are stored in the SGSN and not used for transmis-sion. IPv6 addresses are used for transmission on the network plane. In case of an inter SGSN handover, IPv4 and IPv6 addresses shall be given to the new SGSN in a backward compatible way. If the new SGSN does not support IPv6 ad-dresses, it uses the obtained IPv4 addresses to update the tunnel towards the GGSN. Also the GGSN may start receiving user data from the new SGSN before the tunnel has been updated. Therefore the first and second GGSNs 31, 32 shall be ready to receive GTP packets (signaling or user data) on either IPv4 or IPv6 addresses.
It should be noted, that in future a new SGSN may be provided, which is capable of using only IPv6 on network plane, and same principles would apply.
As an implementation alternative, the node could select the transmission technol-ogy (IPv4 or IPv6) to be used based on operator configuration If the selected GGSN does not support IPv6 in the network plane, it indicates only IPv4 addresses in the corresponding GTP response message. IPv4 addresses are then used for transmission on the network plane as currently defined.
Because it is proposed to send the IPv6 address as a new optional information element, backward compatibility can be provided so as to introduce IPv6 in future network nodes and maintain connections on the network plan even if a new SGSN
supports only IPv4.
In the following, examples for specific signaling messages and the incorporation of a specific address field for transmitting an alternative address will be described with reference to Figs. 2 and 3. Specific details regarding the signaling messages and procedures can be gathered from the 3GPP specifications TS 29.060 and TS
23.060 Release 4.
A Create PDP Context Request is sent from a SGSN node to a GGSN node as a part of the GPRS PDP Context Activation procedure. A valid request initiates the creation of a tunnel between a PDP Context in a SGSN and a PDP Context in a GGSN. If the SGSN prefers to use IPv6 below GTP, it include the IPv6 addresses in new message fields Alternative SGSN Address, and an alternative or equivalent IPv4 address in existing message fields SGSN address. If the GGSN supports IPv6 below GTP, it stores and uses the alternative IPv6 SGSN addresses for communication with the SGSN. If the GGSN supports only IPv4 below GTP, it stores and uses the IPv4 SGSN addresses for communication with the SGSN. The _$_ SGSN accepts packets whether they are sent to its IPv4 or IPv6 address. The GGSN should not store SGSN IP addresses that it does not use. This mechanism provides maximum flexibility, as it is not based on special DNS features, and al-lows the GGSN to have processes using IPv4 only and processes using both IPv4 and IPv6.
The following Table 1 shows the specific information elements provided in the Create PDP Context Request message.
_g_ Table 1:
Information element Presence require-ment IMSI Conditional Recovery Optional Selection mode Conditional Tunnel Endpoint Identifier DataMandatory Tunnel Endpoint Identifier ControlConditional Plane NSAPI Mandatory Linked NSAPI Conditional Charging Characteristics Optional Trace Reference Optional Trace Type Optional End User Address Conditional Access Point Name Conditional Protocol Configuration Options Conditional SGSN Address for signalling Mandatory SGSN Address for user traffic Mandatory Alternative SGSN Address for Optional signalling Alternative SGSN Address for Optional user traffic MSISDN Conditional Quality of Service Profile Mandatory TFT Conditional Trigger Id Optional OMC Identity Optional Private Extension Optional The Create PDP Context Response message is sent from the GGSN node to the SGSN node as a response of a Create PDP Context Request. When the SGSN
receives the Create PDP Context Response with the Cause value indicating 'Re-quest Accepted', the SGSN activates the PDP context and may start to forward PDUs to/from the MT from/to the external data network.
If the GGSN supports IPv6 below GTP, and the SGSN included an IPv6 SGSN
address in the request, the GGSN shall include the IPv6 addresses in the new fields Alternative GGSN Address, and an equivalent IPv4 address in the fields GGSN address. The SGSN uses the alternative IPv6 GGSN addresses for com-munication with the GGSN, except if the operator has configured the use of IPv4.
The SGSN stores the GGSN addresses and sends them to a new SGSN in a PDP
context response message (message sent by old SGSN to new SGSN, after an MS has performed a Routing area update procedure to a new SGSN, that the new SGSN has sent a PDP context request message to the old SGSN). The GGSN
shall accept packets whether they are sent to its IPv4 or IPv6 address. This mechanism avoids losing connection if the new SGSN support IPv4 only below GTP.
Table 2 shows specific information elements provided in the Create PDP Context Response message.
Table 2:
Information element Presence requirement Cause Mandatory Reordering required Conditional Recovery Optional Tunnel Endpoint Identifier Data Conditional Tunnel Endpoint Identifier Control Conditional Plane Charging ID Conditional End User Address Conditional Protocol Configuration Options Optional GGSN Address for Control Plane Conditional GGSN Address for user traffic Conditional Alternative GGSN Address for ControlConditional Plane Alternative GGSN Address for user Conditional traffic Quality of Service Profile Conditional Charging Gateway Address Optional Private Extension Optional Furthermore, an Update PDP Context Request message is sent from a SGSN to a GGSN as part of the GPRS Inter SGSN Routing Update procedure or the PDP
Context Modification procedure or to redistribute contexts due to load sharing.
The SGSN may use SGSN IPv6 addresses only if it has received an IPv6 GGSN
address from an old SGSN (Inter SGSN Routing Area Update case) or GGSN
(PDP context modification). Otherwise SGSN uses SGSN IPv4 addresses.
If the GGSN supports IPv6 below GTP, and the SGSN included an IPv6 SGSN
address in the request, the GGSN includes the IPv6 addresses in the fields Alter-native GGSN Address, and an equivalent IPv4 address in the fields GGSN ad-dress. The SGSN uses the alternative IPv6 GGSN addresses for communication with the GGSN. The SGSN may store both IPv4 and IPv6 GGSN addresses and send them to a new SGSN in PDP context response message. The GGSN
alternative address fields are not sent if the GGSN address field is not sent.
This mechanism guarantees that the SGSN always stores proper IPv4 and IPv6 GGSN
addresses, so that connection will not be lost if moving to a new SGSN
supporting only IPv4 below GTP.
In the following Table 3, specific information elements in the Update PDP
Context Response message are shown.
Table 3:
Information element Presence require-ment Cause Mandatory Recovery Optional Tunnel Endpoint Identifier Data Conditional Tunnel Endpoint Identifier ControlConditional Plane Charging ID Conditional GGSN Address for Control Plane Conditional GGSN Address for User Traffic Conditional Alternative GGSN Address for ControlConditional Plane Alternative GGSN Address for user Conditional traffic Quality of Service Profile Conditional Charging Gateway Address Optional Private Extension Optional Furthermore, as regards the SGSN Context Request message, the new SGSN
sends this message to the old SGSN to get the mobility management (MM) and PDP Contexts for the MT. The old SGSN responds with an SGSN Context Re-sponse.
The new SGSN adds an SGSN Address for the control plane. If the new SGSN
supports IPv6 below GTP, it adds its IPv6 address in the field Alternative SGSN
Address for Control Plane. The old SGSN then selects the SGSN address for Con-trot Plane depending on its IPv6 supports, and stores this selected SGSN
Address and uses it when sending control plane messages for the MT to the new SGSN in the SGSN context transfer procedure.
Table 4 shows specific information elements provided in the SGSN Context Re-quest message.
Table 4:
Information element Presence require-ment IMSI Conditional Routing Area Identity (RAI) Mandatory Temporary Logical Link IdentifierConditional (TLLI) Packet TMSI (P-TMSI) Conditional P-TMSI Signature Conditional MS Validated Optional Tunnel Endpoint Identifier ControlMandatory Plane SGSN Address for Control Plane Mandatory Alternative SGSN Address for Conditional Control Plane Private Extension Optional The old SGSN sends an SGSN Context Response message to the new SGSN as a response to a previous SGSN Context Request. The old SGSN may use SGSN
IPv6 addresses only if it received IPv6 SGSN address from the new SGSN. Oth-erwise SGSN shall use SGSN IPv4 addresses.
The new SGSN sends an SGSN Context Acknowledge message to the old SGSN
as a response to the SGSN Context Response message. Only after receiving the SGSN Context Acknowledge message, the old SGSN starts to forward user data packets. SGSN Context Acknowledge indicates to the old SGSN that the new SGSN has correctly received PDP Context information and is ready to receive user data packets.
The new SGSN uses an SGSN Address for user traffic, which may differ from that provided by the underlying network service (e.g. IP). The old SGSN stores this SGSN Address and uses it when sending downlink PDUs to the new SGSN for the MT. The SGSN may use IPv6 addresses only if it received IPv6 SGSN address for control plane from the old SGSN. Otherwise the SGSN use SGSN IPv4 ad-dresses.
Fig. 2 shows a signaling diagram indicating an Inter-SGSN routing area update procedure according to the preferred embodiment.
In this signaling example, the MT sends a Routing Area Update Request to a new SGSN, so as to initiate a routing area update. In response thereto, the new SGSN
sends an SGSN Context Request message including the SGSN Address fields and the Alternative SGSN Address fields to the old SGSN. In response thereto, the old SGSN returns an SGSN Context Response message in which the desired address type is set in the SGSN Address for Control Plane fields, and all GGSN
IPv4 and IPv6 addresses are included if available. The new SGSN responds with an SGSN Context Acknowledge message including the used address type infor-oration. Then, the new SGSN sends an Update PDP Context Request message including the set address type information to the respective GGSN. This message is sent using a GGSN IP address received from old SGSN. If the new SGSN and GGSN support IPv6 on the network plane, the IPv6 address of GGSN is preferably used. If either SGSN or GGSN does not support IPv6, IPv4 addresses are used.
Here, it is assumed that in a first phase of transition towards IPv6, all nodes sup-port IPv4. The GGSN returns an Update PDP Context Response message includ-ing the GGSN Address fields and the Alternative GGSN Address fields. These ad-dress fields are especially necessary in the following cases:
- The old SGSN supported only IPv4, and had not stored the alternative GGSN address, so that the new SGSN needs to receive it from GGSN to be able to use IPv6 for the connection - The GGSN has changed its IP address (typically due to a reallocation of the PDP context to a new processing card) In addition, if for some reason, the GGSN is configured to use IPv4 to communi-cate towards the new SGSN (due to possible problem in intermediate IP
network), the GGSN will return only the IPv4 addresses and will not send an alternative ad-dress field containing the IPv6 address.
Finally, the required routing area update procedure is performed.
As a further GTP signalling message, a Forward Relocation Request message is defined, which is sent by an old SGSN to a new SGSN to convey necessary in-formation to perform an SRNS (Serving Radio Network Subsystem) relocation procedure between the new SGSN and a target RNC (Radio Network Controller) of the UTRAN. In this case, the old SGSN adds an SGSN Address for Control Plane field information. If the old SGSN supports IPv6 below GTP, it adds its IPv6 address in this field Alternative SGSN Address for Control Plane. The new SGSN
selects the SGSN address for Control Plane depending on its IPv6 supports, and stores this selected SGSN address and uses it when sending control plane mes-sages for the MT to the old SGSN in the SRNS relocation procedure.
Table 5 shows specific information elements provided in the Forward Relocation Request message.
Table 5:
Information element Presence requirement IMSI Mandatory Tunnel Endpoint Identifier ControlMandatory Plane RANAP Cause Mandatory MM Context Mandatory PDP Context Conditional SGSN Address for Control plane Mandatory Alternative SGSN Address for ControlOptional plane Target Identification Mandatory UTRAN transparent container Mandatory Private Extension Optional The new SGSN sends a Forward Relocation Response message to the old SGSN
as a response to a previous Forward Relocation Request message. The new SGSN adds an SGSN Address for Control Plane information. The SGSN may insert IPv6 addresses only if it received an IPv6 SGSN address for control plane from the old SGSN. Otherwise the new SGSN uses SGSN IPv4 addresses. The old SGSN stores this SGSN address and uses it when sending control plane mes-sages for the MT to the new SGSN in the SRNS relocation procedure.
Fig. 3 shows a signaling diagram indicating an SRNS (Serving Radio Network Subsystem) relocation procedure according to the preferred embodiment.
In this signaling example, a source SRNS of the UTRAN decides to perform or initiate an SRNS relocation and sends a Relocation Required message to the old SGSN. In response thereto, the old SGSN determines if the SRNS relocation is an inter-SGSN SRNS relocation and, if so, it sends a Forward Relocation Request message including the SGSN Address field and the Alternative SGSN Address field for control plane signaling to the respective new SGSN. In response thereto, the new SGSN send a Relocation Request message to the target Radio Network Controller (RNC) of the UTRAN. Then, the lu bearers of the radio access bearers (RABs) are setup between the target RNC and the new SGSN as the existing ra-dio bearers will be reallocated between the MT and the target RNC when the tar-get RNC takes the role of the Serving RNC in the new SRNS. After the new SGSN
has received the Relocation Request Acknowledgement message from the UTRAN, the GTP tunnels are established between the target RNC and the new SGSN. Then, the Forward Relocation Response message is sent from the new SGSN to the old SGSN to thereby indicate that the target RNC is ready to receive from the source SRNC (Serving RNC) of the SRNS the forwarded packet data units (PDUs). The old SGSN continues the SRNS relocation by sending a Reloca-tion Command message to the source SRNC. The source SRNC is now ready to forward downlink user data directly to the target RNC. When the data forwarding is completed, the target RNC send a relocation Detect message to the new SGSN.
In response thereto, the new SGSN sends an Update PDP Context Request mes-sage to a concerned GGSN. The GGSN returns an Update PDP Context Re-spouse message including the GGSN Address fields and the Alternative GGSN
Address fields. When the new SGSN receives a Relocation Complete message from the SRNC, a Forward Relocation Complete signaling is exchanged between the new and the old SGSNs , and then the old SGSN initiates an lu release proce-dure at the SRNC. Finally, if the new Routing Area Identification is different, the MT initiates a Routing Area Update procedure.
Furthermore, a PDP Context information element contains the Session Manage-ment parameters, defined for an external packet data network address, that are necessary to transfer between SGSNs at the Inter SGSN Routing Area Update procedure.
If the GGSN negotiated the use of IPv6 below GTP with the old SGSN, the old SGSN sets Alternative GGSN Address for User Traffic and Alternative GGSN Ad-dress for Control Plane fields to contain the IPv6 addresses to be used to commu-nicate with the GGSN. A new SGSN not supporting IPv6 below GTP ignores these alternative GGSN addresses, and uses for communication the GGSN Address for User Traffic and GGSN Address for Control Plane fields. A new SGSN supporting IPv6 below GTP stores the GGSN Address for User Traffic and GGSN Address for Control Plane, but uses use for communication the Alternative GGSN Address for User Traffic and Alternative GGSN Address for Control Plane.
In Table 6, a PDP Context information field is shown.
Table 6 1 Type =
(Decimal) 2-3 Length 4 Res-VAA Res-OrderNSAPI
erved erved X X X X SAPI
6 QoS
Sub Length 7 - QoS
(q+6) Sub [4..255]
Q+7 QoS
Req Length (q+8)-(2q+7)QoS
Req [4..255]
2q+8 QoS
Neg.
Length (2q+9~(3q+8)QoS
Neg [4..255]
(3q+9)-(3q+10)Sequence Number Down (SND) (3q+11 Sequence )- Number (3q+12)Up (SNU) '' 3q+13 Send N-PDU
Number 3q+14 Receive N-PDU
Number (3q+15)-Uplink (3q+18)Tunnel Endpoint Identifier Control Plane (3q+19)-UpIinkTunnel (3q+22)Endpoint Identifier Data I
3q+23 PDP
Context Identifier 3q+24 Spare PDP Type Organisation 3q+25 PDP
Type Number 3q+26 PDP
Address Length (3q+27)-mPDP
Address [1..63]
M+1 GGSN
Address for control plane Length (m+2)-nGGSN
Address for control plane [4..16]
N+1 GGSN
Address for User Traffic Length (n+2)-oGGSN
Address for User Traffic [4..16]
O+1 APN
length (o+2)-pAPN
P+1 Spare Transaction Identifier (sent as 0) P+2 Transaction Identifier Alternative GGSN
Address for control plane Length Alternative GGSN
Address for control plane [4..16]
Alternative GGSN
Address for User Traffic Length Alternative GGSN
Address for User Traffic [4..16]
If having either IPv6 or IPv4 address in GGSN Address for Control Plane is al-lowed, GGSN Address for Control Plane of the PDP context information field may sometimes be an IPv6 address and sometimes an IPv4 address during an active PDP context. This may happen e.g. if GGSN indicates IPv6 address in GGSN Ad-dress for Control Plane and IPv4 address in Alternative GGSN Address for Control Plane at PDP context activation, whereas an old SGSN indicates IPv4 address in GGSN Address for Control Plane to a new SGSN at routing area update. In this case, GGSN Address for Control Plane is the same in GGSN and old SGSN, whereas GGSN Address for Control Plane is different in new SGSN. In this case, e.g. charging correlation by using GGSN Address for Control Plane does not work.
According to the preferred embodiment, a GGSN supporting both IPv6 and IPv4 adds both IPv6 address and IPv4 address to CDRs (Call Detailed Records) cre-ated for a PDP context, i.e. to G-CDRs. The SGSN may add either one IP ad-dress, i.e. GGSN Address for Control Plane, or two IP addresses, i.e. GGSN Ad-dress for Control Plane and Alternative GGSN Address for Control Plane, to the CDRs created for the PDP context, i.e. to S-CDRs. This way, it is possible for the CGF (Charging Gateway Functionality) to correlate CDRs created by the GGSN
(including both IPv6 address and IPv4 address) and CDRs created by the SGSN(s) (including either one IP address, IPv6 or IPv4, or including both IPv6 ad-dress and IPv4 address).
In addition to charging, correlation may be~ needed e.g. for lawful interception or CAMEL messages or information. In general, any message or information gener-ated by multiple nodes can be correlated based on the address and alternative address information. For lawful interception correlation, GGSN sends both IPv6 address and IPv4 address, whereas SGSN may send either one IP address, i.e.
GGSN Address for Control Plane, or two IP addresses, i.e. GGSN Address for Control Plane and Alternative GGSN Address for Control Plane. GGSN thus sends both IPv6 address and IPv4 address, whereas SGSN may send either IPv6 ad-dress or IPv4 address or both for lawful interception correlation. This way, it is possible to correlate e.g. lawful interception information created by GGSN for the PDP context and lawful interception information created by SGSN(s) for the PDP
context.
It is noted that the present invention can be implemented in any cellular network to provide address backward compatibility or message correlation function, when an address information is transferred between network nodes. The names of the vari-ous functional entities, signaling messages and information elements used in the context of the preferred embodiment are not intended to limit or restrict the inven-tion. The preferred embodiments may thus vary within the scope of the attached claims.
Claims (32)
1. A method for providing an address or network transition if a connection point at one end of a connection is changed from a first network node to a second network node of a cellular network, said method comprising the steps of:
a) transmitting an address information and at least one alternative address information in a signaling message from said first network node to said second network node;
b) selecting one of said address information and said alternative address information at said second network node; and c) using said selected address information for re-establishing said connec-tion towards a third node at the other end of said connection.
a) transmitting an address information and at least one alternative address information in a signaling message from said first network node to said second network node;
b) selecting one of said address information and said alternative address information at said second network node; and c) using said selected address information for re-establishing said connec-tion towards a third node at the other end of said connection.
2. A method according to claim 1, wherein, when establishing said connection, possible addresses to be used for this connection are transmitted as said address information and said at least one alternative address information in a signaling message from said first network node to said third network node, and addresses of said third node are stored in said first network node.
3. A method according to claim 1 or 2, where said address information can be used to address a node according to an old addressing or network, used before the transition, and said alternative address information can be used to address a node according to the new addressing or network.
4. A method according to any one of the preceding claims, wherein said sig-naling message is sent as part of a location or routing area update mes-sage or a relocation procedure.
5. A method according to any one of the preceding claims, wherein said sig-naling message is a GTP message.
6. A method according to any one of the preceding claims, wherein said first and second network nodes are SGSNs, and said third network node is a GGSN.
7. A method according to any one of the preceding claims, wherein said ad-dress information and said alternative address information are a user and/or network addresses.
8. A method according to claim 7, wherein said address information and said alternative address information are IPv4 or IPv6 addresses.
9. A method according to any one of the preceding claims, wherein said ad-dress information and said alternative address information are transmitted in respective predetermined fields of said signaling message.
10. A method according to claim 9, wherein said predetermined fields are pro-vided in a PDP context information field.
11. A method according to any one of the preceding claims, wherein said alter-native address information is coded as an optional information so that a network node not supporting said alternative address information ignores it.
12. A method according to claim 11, wherein said connection is re-established with an old addressing mechanism based on said address information if said second node ignores said alternative address information.
13. A method for providing a message correlation function in a data network, said method comprising the steps of:
a) adding an address information and at least one alternative address in-formation to a message at a first network node;
b) selecting one of said address information and said alternative address information at a second network node to which said message has been routed; and c) using said selected address information for correlating said message to a message received from a third network node.
a) adding an address information and at least one alternative address in-formation to a message at a first network node;
b) selecting one of said address information and said alternative address information at a second network node to which said message has been routed; and c) using said selected address information for correlating said message to a message received from a third network node.
14. A method according to claim 13, wherein said message is a call record for charging purposes.
15. A method according to claim 13 or 14, wherein said second network node is a charging gateway functionality.
16. A method according to claim 13, wherein said message is a lawful intercep-tion information or an information of a customized application.
17. A system providing an address or network transition, said system compris-ing:
a) a first network node for transmitting an address information and at least one alternative address information in a signaling message if a connec-tion point at one end of a connection is changed from said first network node; and b) a second network node for receiving said signaling message if said con-nection point is changed to said second network node, for selecting one of said address information and said alternative address information, and for using said selected address information for re-establishing said connection towards a third network node at the other end of said con-nection.
a) a first network node for transmitting an address information and at least one alternative address information in a signaling message if a connec-tion point at one end of a connection is changed from said first network node; and b) a second network node for receiving said signaling message if said con-nection point is changed to said second network node, for selecting one of said address information and said alternative address information, and for using said selected address information for re-establishing said connection towards a third network node at the other end of said con-nection.
18. A system according to claim 17, wherein said first and second network nodes are SGSNs of a GPRS backbone network, and wherein said third network node is a GGSN of said GPRS backbone network.
19. A system for providing a message correlation function in a data network, said system comprising:
a) a first network node for adding an address information and at least one alternative address information to a message;
b) a second network node for receiving said selecting one of said address information and said alternative address information to which said message has been routed; and c) using said selected address information for correlating said message to a message received from a third network node.
a) a first network node for adding an address information and at least one alternative address information to a message;
b) a second network node for receiving said selecting one of said address information and said alternative address information to which said message has been routed; and c) using said selected address information for correlating said message to a message received from a third network node.
20. A system according to claim 19, wherein said message is a call record for charging purposes.
21. A system according to claim 19 or 20, wherein said second network node has a charging gateway functionality.
22. A system according to claim 19, wherein said message is a lawful intercep-tion information or an information of a customized application.
23. A network node of a cellular network, said network node being arranged to transmit an address information and at least one alternative address infor-mation in a signaling message, if a connection point at one end of a con-nection is changed from said network node to another network node.
24. A network node according to claim 23, where said transmitted address information and said at least one alternative address information is used to reestablish said connection towards a third node.
25. A network node according to claim 24, wherein said network node is adapted to store said address information and said alternative address in-formation in order to be used to address said third network node.
26. A network node according to any one of claims 23 to 25, wherein said net-work node is an SGSN.
27. A network node of a cellular network, said network node being arranged to receive a message if a connection point at one end of a connection is changed from another network node to said network node, to select one of an address information and an alternative address information provided in said message, and to use said selected address information for re-establishing said connection towards a third network node at the other end of said connection.
28. A network node according to claim 27, wherein said network node is adapted to receive data and/or signaling either on said address information or on said alternative address information.
29. A network node according to claim 27 or 28, wherein said network node is a GGSN.
30. A network node of a cellular network, said network node being arranged to receive a message if a connection point at one end of a connection is changed from another network node to said network node, to select one of an address information and an alternative address information provided in said message, and to use said selected address information for correlating said message to a message received from a third network node.
31. A network node according to claim 30, wherein said network node has a charging gateway functionality, and said signaling message is a charge re-cord.
32. A network node according to claim 30, wherein said message is a lawful interception information or an information of a customized application.
Applications Claiming Priority (5)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| EPPCT/EP01/11525 | 2001-10-05 | ||
| PCT/EP2001/011525 WO2003032668A1 (en) | 2001-10-05 | 2001-10-05 | Method and system for hand off in a gprs network with nodes supporting different ip versions |
| EPPCT/EP02/00351 | 2002-01-15 | ||
| EP0200351 | 2002-01-15 | ||
| PCT/IB2002/004079 WO2003032604A1 (en) | 2001-10-05 | 2002-10-04 | Address transition and message correlation between network nodes |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2462701A1 true CA2462701A1 (en) | 2003-04-17 |
Family
ID=26069226
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002462701A Abandoned CA2462701A1 (en) | 2001-10-05 | 2002-10-04 | Address transition and message correlation between network nodes |
Country Status (10)
| Country | Link |
|---|---|
| US (1) | US7818453B2 (en) |
| JP (1) | JP3834036B2 (en) |
| KR (2) | KR20060135946A (en) |
| CN (2) | CN100542165C (en) |
| AT (1) | ATE348476T1 (en) |
| CA (1) | CA2462701A1 (en) |
| DE (1) | DE60216791T2 (en) |
| PL (1) | PL369412A1 (en) |
| RU (1) | RU2273104C2 (en) |
| WO (1) | WO2003032604A1 (en) |
Families Citing this family (49)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7076254B2 (en) * | 2001-04-25 | 2006-07-11 | Nokia Corporation | Telecommunication network having at least two network entities, and communication method |
| GB2387069A (en) * | 2002-03-27 | 2003-10-01 | Ericsson Telefon Ab L M | Indicating different charging regimes for user and signalling data in a communications network |
| KR100886551B1 (en) * | 2003-02-21 | 2009-03-02 | 삼성전자주식회사 | Apparatus for traffic flow template packet filtering according to internet protocol version in mobile communication system and method thereof |
| US20060251018A1 (en) * | 2003-05-05 | 2006-11-09 | Siemens Aktiengesellschaft | Method and device for intermediate storage of subscriber data during a relocation of a mobile subscriber within a mobile communication network |
| KR100803590B1 (en) * | 2003-10-31 | 2008-02-19 | 삼성전자주식회사 | System for providing tunnel service capable of data communication between different type of networks |
| KR20050054663A (en) | 2003-12-05 | 2005-06-10 | 한국전자통신연구원 | A method for balancing load in gprs network and call set-up method thereby |
| US7440459B2 (en) * | 2004-02-02 | 2008-10-21 | Lucent Technologies Inc. | Methods of detecting protocol support in wireless communication systems |
| GB0402657D0 (en) * | 2004-02-06 | 2004-03-10 | Nokia Corp | A communication system |
| GB0406094D0 (en) * | 2004-03-17 | 2004-04-21 | Koninkl Philips Electronics Nv | Making time-of-flight measurements in master/slave and ad hoc networks by evesdropping on messages |
| KR100596401B1 (en) * | 2004-04-07 | 2006-07-03 | 한국전자통신연구원 | Method for a mobile node establishing a mobile internet protocol and for performing handoff by a mobile node |
| US8429393B1 (en) * | 2004-09-30 | 2013-04-23 | Rockwell Automation Technologies, Inc. | Method for obscuring a control device's network presence by dynamically changing the device's network addresses using a cryptography-based pattern |
| US7873817B1 (en) * | 2004-10-19 | 2011-01-18 | Broadcom Corporation | High speed multi-threaded reduced instruction set computer (RISC) processor with hardware-implemented thread scheduler |
| CN1302651C (en) * | 2004-11-10 | 2007-02-28 | 华为技术有限公司 | A service universal block radio business supporting internodel communication method |
| US7167459B2 (en) * | 2004-12-30 | 2007-01-23 | Motorola, Inc. | Inter-network handover in a packet radio system |
| EP2950583B1 (en) | 2005-05-12 | 2020-06-03 | Apple Inc. | Using an access point name to select an access gateway node |
| KR101238993B1 (en) * | 2005-08-25 | 2013-03-04 | 엘지전자 주식회사 | Traffic transmission path relocation method for radio communication system |
| WO2007073252A1 (en) * | 2005-12-22 | 2007-06-28 | Telefonaktiebolaget Lm Ericsson (Publ) | Provisioning of user information |
| JP4715521B2 (en) * | 2006-01-10 | 2011-07-06 | 株式会社日立製作所 | Communication system and call control server |
| US20070213057A1 (en) * | 2006-03-08 | 2007-09-13 | Interdigital Technology Corporation | Method and apparatus for supporting routing area update procedures in a single tunnel gprs-based wireless communication system |
| US20070213058A1 (en) * | 2006-03-08 | 2007-09-13 | Interdigital Technology Corporation | Method and apparatus for supporting handoff and serving radio network subsystem relocation procedures in a single tunnel gprs-based wireless communication system |
| AU2007222105A1 (en) * | 2006-03-08 | 2007-09-13 | Interdigital Technology Corporation | Method and apparatus for supporting routing area update procedures in a single tunnel GPRS-based wireless communication system |
| US8189509B2 (en) * | 2006-03-13 | 2012-05-29 | Telefonaktiebolaget Lm Ericsson (Publ) | Method of controlling packet data traffic |
| US20070271453A1 (en) * | 2006-05-19 | 2007-11-22 | Nikia Corporation | Identity based flow control of IP traffic |
| US8331961B1 (en) * | 2006-06-12 | 2012-12-11 | Apple, Inc. | Transfer of emergency services session between disparate subsystems |
| CN101507308A (en) * | 2006-08-16 | 2009-08-12 | 艾利森电话股份有限公司 | GGSN proxy for one tunnel solution |
| CN104244219B (en) * | 2006-08-16 | 2018-04-20 | 艾利森电话股份有限公司 | GGSN for a tunnel solution is acted on behalf of |
| US7920522B2 (en) * | 2006-09-29 | 2011-04-05 | Qualcomm Incorporated | Method and apparatus for system interoperability in wireless communications |
| RU2456777C2 (en) * | 2006-12-22 | 2012-07-20 | Телефонактиеболагет Лм Эрикссон (Пабл) | Method and device for communication device configuration |
| US9155118B2 (en) * | 2007-01-22 | 2015-10-06 | Qualcomm Incorporated | Multi-link support for network based mobility management systems |
| US7908386B2 (en) * | 2007-04-04 | 2011-03-15 | Telefonaktiebolaget L M Ericsson Publ) | Large scale mobile network address translation |
| JP5275336B2 (en) * | 2007-04-06 | 2013-08-28 | インターデイジタル テクノロジー コーポレーション | Method and apparatus for identifying network protocol capabilities |
| US8559321B2 (en) | 2007-06-08 | 2013-10-15 | Qualcomm Incorporated | Mobile IP home agent discovery |
| EP2174521B1 (en) * | 2007-07-13 | 2015-10-21 | Telefonaktiebolaget L M Ericsson (publ) | Method for reducing the control signaling in handover situations |
| CN101420762B (en) * | 2007-10-23 | 2011-02-23 | 中国移动通信集团公司 | Access gateway selection method, system and gateway selection execution node |
| US8782278B2 (en) * | 2008-03-21 | 2014-07-15 | Qualcomm Incorporated | Address redirection for nodes with multiple internet protocol addresses in a wireless network |
| US20090279543A1 (en) * | 2008-05-06 | 2009-11-12 | Lucent Technologies Inc. | Method and System for Handling Tethered User Devices in a Telecommunications Network |
| JP5529868B2 (en) * | 2008-08-14 | 2014-06-25 | サムスン エレクトロニクス カンパニー リミテッド | Method and system for processing dynamic host configuration protocol IPv4 address release request |
| US10015729B2 (en) * | 2008-11-17 | 2018-07-03 | Telefonaktiebolaget L M Ericsson (Publ) | Providing access to a GPRS network |
| US9480092B2 (en) * | 2009-04-23 | 2016-10-25 | Qualcomm Incorporated | Establishing packet data network connectivity for local internet protocol access traffic |
| US8730911B2 (en) | 2009-05-08 | 2014-05-20 | Futurewei Technologies, Inc. | System and method for redirecting messages to an active interface of a multiple-interface device |
| JP5277154B2 (en) * | 2009-12-24 | 2013-08-28 | 株式会社エヌ・ティ・ティ・ドコモ | Mobile communication method and switching center |
| JP4740368B2 (en) * | 2009-12-24 | 2011-08-03 | 株式会社エヌ・ティ・ティ・ドコモ | Mobile communication method and switching center |
| CN102316433B (en) * | 2010-07-06 | 2016-06-15 | 中兴通讯股份有限公司 | A kind of method and system of ticket information reporting |
| ES2530948T3 (en) * | 2010-10-05 | 2015-03-09 | Ericsson Telefon Ab L M | Call establishment termination technique in a CSFB situation |
| WO2012130263A1 (en) | 2011-04-01 | 2012-10-04 | Siemens Enterprise Communications Gmbh & Co. Kg | Method for addressing messages in a computer network |
| CN102892109B (en) * | 2011-07-21 | 2018-05-11 | 中兴通讯股份有限公司 | A kind of method and system for realizing IP address property notification |
| US8812694B2 (en) * | 2011-12-22 | 2014-08-19 | Blackberry Limited | Dialog establishment over a peer-to-peer architecture |
| DK2658333T3 (en) * | 2012-04-26 | 2015-12-14 | Belgacom Internat Carrier Services | APN Correction System and Procedure in GTP Messages for GPRS Data Services Provided by a Mobile Operator Using a Sponsor Network |
| CN111225072B (en) * | 2018-11-26 | 2022-07-19 | 本无链科技(深圳)有限公司 | Dynamic addressing method and system based on block chain |
Family Cites Families (15)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| FR2746992B1 (en) * | 1996-03-27 | 1998-09-04 | Quinquis Jean Paul | LOCAL MOBILE ACCESS NETWORK |
| US6172986B1 (en) * | 1997-05-13 | 2001-01-09 | Hitachi, Ltd. | Mobile node, mobile agent and network system |
| FI107007B (en) * | 1998-10-12 | 2001-05-15 | Nokia Networks Oy | Method for maintaining a connection between an intelligent network control point and access point in a telecommunication system and a telecommunication system |
| CA2281431A1 (en) * | 1998-10-28 | 2000-04-28 | Lucent Technologies Inc. | Mobile-tcp and method of establishing and maintaining a mobile-tcp connection |
| US6408173B1 (en) * | 1999-03-17 | 2002-06-18 | Telefonaktiebolaget L M Ericsson (Publ) | Billing ID correlation for inter-technology roaming |
| GB9923866D0 (en) | 1999-10-08 | 1999-12-08 | Hewlett Packard Co | Correlation of signalling messages |
| GB0000927D0 (en) * | 2000-01-14 | 2000-03-08 | Nokia Networks Oy | Communication method and system |
| DE10001608A1 (en) * | 2000-01-17 | 2001-07-19 | Bosch Gmbh Robert | Operating method for mobile radio network, involves stopping packet forwarding to primary base station, based on the identifier, when the connection between mobile and secondary base stations is switched |
| FI20001544A (en) * | 2000-06-29 | 2001-12-30 | Nokia Networks Oy | Network support for abnormal terminal |
| FI110400B (en) * | 2000-07-03 | 2003-01-15 | Nokia Corp | A method, terminal, and system for managing multiple mailboxes |
| US7039027B2 (en) * | 2000-12-28 | 2006-05-02 | Symbol Technologies, Inc. | Automatic and seamless vertical roaming between wireless local area network (WLAN) and wireless wide area network (WWAN) while maintaining an active voice or streaming data connection: systems, methods and program products |
| US8019335B2 (en) * | 2001-01-29 | 2011-09-13 | Nokia Corporation | Identifying neighboring cells in telecommunication network |
| US6856624B2 (en) * | 2001-02-21 | 2005-02-15 | Alcatel | Temporary unique private address |
| US7061894B2 (en) * | 2001-08-07 | 2006-06-13 | Industrial Technology Research Institute | System and method for providing voice communications for radio network |
| US20080268850A1 (en) * | 2007-04-30 | 2008-10-30 | Motorola, Inc. | Method and apparatus for handover in a wireless communication system |
-
2002
- 2002-10-04 KR KR1020067023436A patent/KR20060135946A/en not_active Application Discontinuation
- 2002-10-04 JP JP2003535437A patent/JP3834036B2/en not_active Expired - Lifetime
- 2002-10-04 KR KR1020047004623A patent/KR100693975B1/en active IP Right Grant
- 2002-10-04 CN CNB028196082A patent/CN100542165C/en not_active Expired - Lifetime
- 2002-10-04 US US10/491,664 patent/US7818453B2/en active Active
- 2002-10-04 CA CA002462701A patent/CA2462701A1/en not_active Abandoned
- 2002-10-04 PL PL02369412A patent/PL369412A1/en not_active Application Discontinuation
- 2002-10-04 WO PCT/IB2002/004079 patent/WO2003032604A1/en active IP Right Grant
- 2002-10-04 AT AT02772680T patent/ATE348476T1/en not_active IP Right Cessation
- 2002-10-04 DE DE60216791T patent/DE60216791T2/en not_active Expired - Lifetime
- 2002-10-04 CN CN2009101268721A patent/CN101511081B/en not_active Expired - Lifetime
- 2002-10-04 RU RU2004110040/09A patent/RU2273104C2/en active
Also Published As
| Publication number | Publication date |
|---|---|
| US7818453B2 (en) | 2010-10-19 |
| DE60216791D1 (en) | 2007-01-25 |
| DE60216791T2 (en) | 2007-10-18 |
| RU2273104C2 (en) | 2006-03-27 |
| RU2004110040A (en) | 2005-09-10 |
| CN101511081A (en) | 2009-08-19 |
| JP3834036B2 (en) | 2006-10-18 |
| KR20040039450A (en) | 2004-05-10 |
| US20040243720A1 (en) | 2004-12-02 |
| ATE348476T1 (en) | 2007-01-15 |
| WO2003032604A1 (en) | 2003-04-17 |
| CN1565116A (en) | 2005-01-12 |
| PL369412A1 (en) | 2005-04-18 |
| KR20060135946A (en) | 2006-12-29 |
| JP2005506002A (en) | 2005-02-24 |
| KR100693975B1 (en) | 2007-03-12 |
| CN100542165C (en) | 2009-09-16 |
| CN101511081B (en) | 2012-09-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7818453B2 (en) | Address transition and message correlation between networks nodes | |
| KR100432311B1 (en) | Gprs-subscriber selection of multiple internet service providers | |
| US8391210B2 (en) | Radio communication system and radio transmission path control method | |
| US8824430B2 (en) | Wireless mobility gateway | |
| EP1560378B1 (en) | Wireless mobility gateway | |
| EP1771978B1 (en) | Tunneling internet protocol packets between a gateway support node and a mobile terminal | |
| US8320309B2 (en) | IP mobility within a communication system | |
| MXPA04012156A (en) | Wlan as a logical support node for hybrid coupling in an interworking between wlan and a mobile communications system. | |
| EP1929716B1 (en) | Preserved bearers | |
| EP1440594B1 (en) | Forwarding a mobile subscriber identity between core network nodes | |
| JP2004519179A (en) | Method for supporting handover between radio access networks | |
| EP1753189A1 (en) | A method for communicating between serving general packet radio service support nodes | |
| EP1543666A2 (en) | A method for a gateway to select a channel for transferring data packets | |
| EP1224819B1 (en) | Packet data service in a mobile communications system | |
| EP1925127B1 (en) | Maintaining of connection between terminal device and service | |
| WO2003032668A1 (en) | Method and system for hand off in a gprs network with nodes supporting different ip versions | |
| JP2011509611A (en) | Techniques for optimizing routes in communication networks | |
| EP1436964B1 (en) | Address transition and message correlation between network nodes | |
| US8417294B2 (en) | Method and system for providing data services in a hybrid network | |
| EP1667384B1 (en) | A method for a gateway to select a channel for transferring data packets | |
| KR100617780B1 (en) | Method for updating routing area of mobile node in wireless internet and mobile communication network |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |