GB2393608A

GB2393608A - Selecting an appropriate PDP context at a GPRS gateway support node for transferring a data packet from a mobile node to a correspondent node

Info

Publication number: GB2393608A
Application number: GB0222161A
Authority: GB
Inventors: Xiaobao Chen; Eyal Trachtman; Elvio Gambaruto
Original assignee: Orange Personal Communications Services Ltd
Current assignee: Orange Personal Communications Services Ltd
Priority date: 2002-09-24
Filing date: 2002-09-24
Publication date: 2004-03-31
Also published as: GB0230335D0; GB0222161D0

Abstract

A GPRS gateway receives a tunnelled data packet from a mobile node MN in a home network and selects a channel for transferring the packet to a correspondent node CN by mapping a PDP address (home address) used by the MN to one or more data packet filters associated with the channels. When the MN roams to a foreign network it is assigned a care of address CoA which is not recognised by the gateway. Therefore the first data packet sent by the MN from the foreign network includes the PDP address used by the MN in the home network. The CoA is then included in the data packet filters.

Description

Telecommunications Field of the Present Invention

Tile present invention relates to apparatus tor and methods of enabling 5 a gateway node of a first packet-switched data network to select a first channel for transferring a data packet to a destination packet data protocol address of a correspondent node provided service in the first network, the gateway node being arranged to select the first channel trom a plurality of channels each being for transferring data packets to the destination packet 10 data protocol address of the correspondent node, the data packet having been sent from a mobile node of a second packetswitched data network external to the first network, the mobile node having been in a communication session with the correspondent node while provided service in a third packet-switched data network different to the second network.

15 More particularly, but not exclusively, the present invention relates to apparatus tor and methods of enabling a Cieneral Packet Radio Service Gateway Support Node (Ci(iSN) of a 2G or 3G General Packet Radio Service (GPRS) network to select an appropriate Packet Data Protocol (PDP) Context tor transferring a data packet, sent by a Mobile Node (MN) in an external IP 20 network, to a Correspondent Node (CN) in the GPRS network, where macro mobility of the MN is supported using the Mobile Internet Protocol, the MN is away *om its Home Network (IIN), and where the data packet uses the Care Of Address (CoA, CoCoA) of the MN as its source address.

Background

Whereas conventional 2G mobile networks, such as those conforming to the Global System for Mobile Communications (GSM) standards, have provided circuit-switched voice and data services to user's mobile stations 5 (MSs) , there is great momentum in the mobile telecommunications industry to deploy packet-switched mobile networks. Packet-switched mobile networks I have significant advantages in terms ot' network and radio resource efficiency and also enable the provision of more advanced user services. With the convergence of' fixed and mobile telecommunications networks, the Internet 10 Protocol (IP), widespread in fixed networks, is the natural choice as the packet routing mechanism for mobile packet networks. Currently IP version 4 (IPv4) is in widespread use in the fixed network domain. However, it is expected gradually to migrate to IP version 6 (IPv6) which offers well recognised benefits c,ver IPv4, notably in terms of greatly increased address 15 space, more efficient routing, greater scalability, improved security, Quality of Service (QoS) integration, support t'or multicasting and other features.

Particular examples of mobile packet-switched services currently being deployed include the General Packet Radio Service (GPRS) as implemented in both 2G GSM networks and in 3G Universal Mobile 20 Telecommunications System (UMTS) networks (hereinafter referred to as GPRS networks). It is also expected that non-Gl'RS wireless access technologies, such as wireless Local Area Network (wLAN), will provide a flexible and costeffective complement to GPRS for local broadband service

access in some areas such as hotshots (conference centres, airports, exhibition centres, etc). Consequently mobile network operators will want to support roaming of mobile stations between CiPRS and non-GPRS networks or subnetworks. 5 While GPRS networks, having been designed from the start as mobile networks' have built-in mobility management (for MSs within the GPKS network) and roaming functionality (for MSs roaming between GPRS networks), work has also taken place in the Internet F, ngineering Task Force (IETF) to support mobility of IP user terminals in general. To this end, the 10 IETF have developed the Mobile IP (MIP) protocols. MIP is designed to support mobility when mobile stations (or mobile nodes (MNs) in MIP terminology) move between IP networks with di f'l'erent subnet prefixes (macro-mobility). For example, MIP may be used to support mobility between a (,PRS network and a non-GPRS network such as a wLAN 15 network. Mobile IP is not expected to be used for mobility management within a network or subnetwork (micro-mobility) which is typically managed by access technology specific layer 2 mechanisms such as WCDMA softer/sot't handover.

There are two versions of'MIP to correspond to the two versions of IP.

20 MIP version 4 (MIPv4) is designed to provide IP address mobility for IP version 4 (IPv4) addresses, whereas the newer MIP version 6 (MlPv6) MIP is designed to provide IP address mobility for IP version 6 (IPv6) addresses.

MIPv4 is described in the IETF Request For Comment (RFC) 2002 available

( at the IETF website http.//,ww.ieJ:org/rtc/rfc20()2.txtnumber=2()()2.

Intcrnet drat't MlPv6 is described in the IF.TF Internct draft "Mobility Support in IPv6" available at the IETF websitc at http.//search.ietf.'r', '/internet druf?./ciruli-ief:mohileip-ipv6-18.txt and referenced as draftietf-mobileip 5 ipv6- 1 8.txt.

MlPv4 mobility management is illustrated in Figure 1. A MN 40 is allocated a home IP address (HAddr) in its Home Network (I IN) 42. Routing procedures in the HN ensure that wherever the MN is within the KIN, an IP packet sent from a Correspondent Node (CN) 46 will reach the MN.

However, when the MN roams to a foreign network (FN) 44, IP packets addressed to its HAddr will need to be routed to its new location in the FN. In MIPv4, a router 48 in the HN known as the Elome Agent (HA) is used to act as a packet forwarding service on behalf of the MN when it is away Prom home. In a l'irst working mode of MlPv4 (known as FA-CoA mode), when 15 arriving in the FN, the MN is allocated a Care of Address (('oA) by a router 50 in the FN known as the Foreign Agent (FA). Due to perceived limitations of IPv4 address space, it is envisaged that more than one MN may share the same CoA. After allocation of the CoA. the FA 50 sends a binding update to the HA to register the CoA. l'hereaRer, when the CN sends a packet to the 20 HAddr of the MN in its HN (case I), the packet is intercepted by the E IA and tunnellcd to the FA in the FN via tunnel 52 on the basis of the CoA.

Tunnelling involves encapsulating a first data packet (with a header and a payload) as the payload of a second data packet having a new header

( indicating, as its source and destination addresses, the start and end points of the tunnel. and transferring the second data packet as normal to the tunnel endpoint where it is decapsulated to obtain the first packet. After decapsulation, the tunnel end point, the FA, routes the original packet to the 5 MN using routing procedures in the FN. In MIP, tunnelling involves IP in IP encapsulation using the IF,TF Request For Comment (RELIC) 2003. Thus in MlPv4. an IPv4 packet is tunnelled by encapsulating it within another IPv4 packet. As an optional procedure in MlPv4, the MN may then send a binding 10 update to the CN to register its CoA. 'I'hereafter, the CN may address packets directly to the MN at its current CoA, rather than indirectly via its lIAddr (case 2), and these packets are received by the FA in the FN and routed to the MN using routing procedures in the EN. This is known as route optimization since it avoids potentially inef'fcient triangular routing via the lIA which in 15 general will not be on an efficient routing path between the CN and the l'A.

In a second optional working mode of' MlPv4 (known as ('oCoA mode) there is no sharing of CoAs by MNs away from their home network and no FA is used. The MN is allocated a unique CoA. known as a co-located CoA (CoCoA), using standard dynamic IP address allocation procedures - eg 20 using Dynamic l-lost Control Protocol (I)HCP). In this working mode. the MN must itself send a binding update to its HA to register its newly allocated CoCoA. Thereafter, packets sent by a CN and addressed to the MN at its l-lAddr are tunnelled from the HA directly to the MN. As with FA- CoA

mode, as an optional procedure in CoCoA mode, the MN may also send a binding update to a CN to register its CoG,A. Thereafter, packets may be sent by the CN directly to the MN at its CoCoA.

MIPv6 mobility management is illustrated in Figure 2. 'I'wo notable 5 differences of MlPv6 over MlPv4 are as t'ollows. Firstly, due to the greatly increased address space in IPv6, C'oAs allocated to a MN in a FN are never shared (ie they correspond to the optional CoCoA in MIPv4). Secondly, as a result, there is no need to deploy a FA in the FN. Referring to Figure 2, with MlPv6, when a MN 40 moves from its HN 42 to a FN 44, it is allocated a 10 unique CoA and sends a binding update to its HA 48 in its HN to register the CoA. Packets from a CN 46 addressed to the HAddr are intercepted by the HA 48 (case 1) and tunnelled to the CoA via tunnel 54. This tunnelling may be achieved using IPv6 Generic Packet Tunnelling Mechanism described in IETF RFC 2473. However, in MlPv6, route optimization is not an option but 15 a fundamental Tart of the protocol and, in general, the MN should send a binding update to the CN so that it may address packets directly to the MN at its CoA (case 2). When an MN receives a packet tunnelled from a CN via the MN's HA, it may take this as an indication that the CN has no binding for the MN and initiate a CN binding update. Note that in MlPv6 the CN binding 20 update must use the new CoA of the MN as the source address in the IPv6 header (see Clause 11. 6.2 of the MIPv6 IETF Internet draft).

The 3rd Generation Partnership Project (3GPP) responsible for the C,PRS standards has recognised that MIP may need to be supported in GPRS

( networks. Technical Specification 23.060 Clause 5.7 states that "To support

the optional Mobile IP services, see 3G TS 23.121, ef'i'iciently in the packet domain, Foreign Agent (FA) functionality needs to be provided in the GG5N.

The inters ce between the GGSN and FAR including the mapping between the 5 care of' IP address and the (,'I'P tunnel in the PLMN is assumed not to be standardized as the GGSN and FA are considered to be one integrated node."

Furthermore, 3G TS 23.121 (available from the 3GPP website at http //www. 3gpp org/fp/.specs/2()()2-()6MI 9)/23_series/) states that "...it is important to offer Mobile IP also to UM'I'S and GPRS users to allow them to 10 roam to and from other access technologies while keeping ongoing data sessions, e.g. TCP or UDP" and that "as IP addresses in IPv4 are scarce, it has to be assumed that Mobile IPv4 preferably will be used with the Foreign Agent (FA) care-of addresses. Compared to using co- located care-of addresses, I A care-of addresses does not only conserve IP addresses, it is also 15 more ef f'icient cover the radio interface."

I lowever, there may be circumstances in which the above assumptions are false. Firstly, a GPRS network operator may want to use CoC'oAs in MlPv4 instead of' FA CoAs. For instance, IPv4 addresses may not be scarce within a particular GPRS network and CoCoAs may be preferred to improve 20 scalability and routing efficiency. Secondly, there may be circumstances in which the GPRS network operator would not want to integrate FA functionality in the Gateway GPRS Support Node (GGSN) which is the gateway connecting the GPRS network to external packet-switched networks.

( For instance, the GGSN may be heavily loaded and separating the CGGSN and PA functionality would improve load balancing. Furthermore, it may be considered beneficial to locate the FA in nodes which are closer to the edges of the GPRS network, such as access nodes, t'or improved scalability.

5 Thirdly, the 3GPP has itself recently mandated that IPv6 must be supported in lJM'l'S R5 IP Multimedia System (IMS) and IP radio access networks in general. Thus, it is clear that GPRS networks will need to support MIPv6 as well as MlPv4 in future and, as described above, MIPv6 has no PA and uses CoAs which are unique to the MN (ie always "colocated").

10 The present inventors have realised that a problem arises in GPRS networks implemented according to the present service descriptions (Release

1999) in each of the three circumstances listed above. One particular feature of' GPRS networks, which conform to Release 1999 of the GPRS Service Description is support for what are known as packet data protocol (PDP)

15 contexts. Specifying different PUP contexts are useful tor a variety of reasons. In particular' PDP contexts allow differing QoS levels and other parameters to be specified for traffic to and from a single PDP address of a MS. This allows efficient transfer of a variety of data traffic, such as non real-time traffic (eg intermittent and bursty data transfers' occasional transfers 20 of large volumes of data) and real- time traffic (eg voice, video). For example.

a MS in a GPRS network, having a PDP address, such as an IPv4 or IPv6 address, may communicate with a plurality of other telecommunications devices in external packet-switched networks using different PDP contexts

with differing QoS parameters for each one. It is generally the duty of the MS to create and modify PDP contexts as required.

Incoming data packets from an external network t'or downlink to a MS are received in the CiPRS network by the (i(iSN. If the PDP address of the 5 MS has multiple PDP contexts established, it is essential that the (i(iSN be able to determine the appropriate P[)P context for each packet so that it may be transferred appropriately to the MS. This is achieved by using 'I'raffic Flow 'I'emplates (TFTs) associated with PDP contexts. The TFTs may contain packet filtering information used by the (i(iSN to determine the 10 appropriate PDP context for downlink data packets. According to current 3GPP standards. one specified item of information for use in packet filtering is the source address of the incoming data packet - eg the IP address of the source node as specified in the IP packet header. When an incoming, data packet arrives at the (i(iSN' its source address is checked against existing 15 TFTs associated with the PUP address <of the MS. If a match is found' the packet is transferred to the MS at its PDP address according to the appropriate PDP context. If, however, no match is found, the packet may be dropped by the GGSN. Here is where the problem arises.

Let us suppose that the telecommunications device in communication 20 with the MS is itself a mobile device and is provided macro-mobility using either MlPv4 or MlPv6. Let us also suppose that it has just moved to a new F N and has been allocated a new CoA (or possibly G,CoA) for use in that EN. Let us now call the MS in the GPRS network a CN and the

telecommunications device in the external network a MN for consistency.

The CN may already have a PDP context established for the communication session with the MN using the MN's IlAddr as a source address in the TFT packet filtering information. However, after moving to the new EN, any data 5 packets now sent t'rom the MN to the CN will have the new CoA (or CoCoA) as their source address in the IPv4 or IPv6 header. Thus, an incoming data packet arriving at the GGSN in the GPRS network will not be recognised by the GGSN using the TET identifying the MN's IlAddr as the source address and may be dropped.

10 This problem applies not only to user data packets sent by the MN to the CN, but also to signalling data packets such as a correspondent binding update packet that the MN's I IA may (MlPv4) or MN should (MlPv6) send to the CN. The MN correspondent binding update will also use the new CoA/('oCoA as the source address (see Clause 11.6.2 of the MlPv6 1E'1t' 15 Internet draft) and this will not be recognised by the GGSN. Thus, the CN in the GPRS network is caught in a circular trap in that it cannot receive a correspondent binding update from the MN, because it has not received the MN's new CoA/CoCoA. But it cannot receive the MN's new CoA/CoCoA, because it has not received a correspondent binding update - "Catch 22".

20 The present invention provides a solution to the above problem.

Summary of the Present Invention

According to a first aspect of the present invention. there is provided a method of enabling a gateway node of a first packet-switched data network to S select a first channel for transferring a data packet to a destination packet data protocol address o f a correspondent node provided service in the first network, the gateway node being arranged to select the first channel from a plurality of channels each being for transferring data packets to the destination packet data protocol address of the correspondent node, the data packet 10 having been sent from a mobile node of a second packet-switched data network external to the first network, the mobile node having been in a communication session with the correspondent node while provided service in a third packet- switched data network dift'erent to the second network, the method comprising: 15 a) the mobile node associating with the data packets a first packet data protocol address which it used in the communication session with the correspondent node; b) the gateway node selecting the first channel by matching the first packet data protocol address associated with the data packet received by 20 the gateway node to a first data packet filter associated with the first channel.

Further aspects of the present invention include a mobile node and a gateway node arranged in accordance with the method of the second aspect described above. I

( According to a second aspect of the present invention there is provided a method of enabling a gateway node of a first packet-switched data network to select a first channel for transferring a data packet to a destination packet data protocol address of a correspondent node provided service in the first 5 network, the gateway node being arranged to select the first channel from a plurality of channels each being for transferring data packets to the destination packet data protocol address of the correspondent node, the data packet having been sent from a mobile node ot a second packet-switched data network external to the first network, the mobile node having been in a 10 communication session with the correspondent node while provided service in a third packet-switched data network different to the second network, wherein mobility of the mobile node between networks or subnetworks is supported using the Mobile Internet Protocol (Mll') standards, the mobile node having a home packet data protocol address (llAddr) in the third network, the mobile 15 node having moved to the second network and having been provided with a current packet data protocol address (C'oA. C'oC'oA) in the second network, the method comprising: a) the mobile node sending a MIP correspondent binding update packet addressed to the correspondent node, the MIP correspondent binding 20 update packet having the home packet data protocol address of the mobile node associated with it;

b) the gateway node receiving the correspondent binding update packet and transferring it to the correspondent node using a second channel having no associated data packet filters; c) the correspondent node match the home packet data protocol 5 address of the mobile node associated with the correspondent binding update packet to the communication session with the mobile node; and d) in response to the matching, the correspondent node arranging for the current packet data protocol address of the mobile node to be included in the first data packet filter.

10 Further aspects of the present invention include a correspondent node arranged in accordance with the method of the second aspect described above.

Further aspects of the present invention are set out in the . accompany claims.

I'hcrc now follows, by way of example only, a detailed description of

15 preferred embodiments of the present invention in which: Brief Description of Diagrams

Figure I is a conceptual diagram showing mobility management as provided in MlPv4; 20 Figure 2 is a conceptual diagram showing mobility management as provided in MlPv6;

( Figure 3 is a network architectural diagram showing a GT,RS network and a w[.AN network connected via an external packet-switched network cloud; and Figure 4 is a message flow diagram. showing a PDP context 5 modification procedure in a (iPRS network enabling a GGSN to match tunnelled packets for downlink to a MN to the appropriate tunnel of the PDP context, according to the second and third embodiments of the present invention. 10 Detailed Description of Embodiments of the Present Invention

Figure 3 shows a network architecture in which both a GPRS network 10 and a wI AN network 20 are both connected with one or more external packet networks in external packet network cloud 30.

(iPRS network I O is connected to the external packet networks via one 15 or more Gateway (iPKS Support Nodes (GGSNs) (although here only one (i(iSN 12 is illustrated) which communicate with one or more Serving GPRS Support Nodes (S(iSNs) (although here only one SGSN 14 is illustrated) via an internal IP-based packet-switched backbone network. SGSN 14 keeps track of the location of individual Mobile Stations (MSs) attached to the 20 GPRS service and performs security functions and access control. S(iSN 14 is itself connected to one or more Radio Access Networks (RNSs) 16 (either the Base Station Subsystem (HISS) in the 2(i GSM network or UMTS

( Terrestrial Radio Access Network (UTRAN) in the 3G UMTS network). The RNS's control communication over the air with one or more MSs I X. Other major components ot' (iPRS network 10. such as the Home Location Register (HLR) which stores GSM and UMTS subscription data and 5 the Mobile Switching Centre/Visitor 1,ocation Register (MSC/VLR) which handles circuit-switched services and also keeps track of the location of individual Mobile Stations (MSs), are omitted for clarity. The reader is referred to the GPRS Service Description (release 1999) Technical

Specification, referred to as 3G TS 23.060 v3.12.0 (2002-06) and available

10 from the 3GPP website at hltp.//www.3g'p.or,,,/fip/spec/2)()2 06/R1999/23_series/, which provides a detailed service description for 2G

((iPRS/GSM) and 3G ((iPRS/lJM'l'S) mobile packet networks. The functionality of GPRS networks is also generally well-known, although further aspects will be described in detail below.

15 WEAN network 20 is connected to the external packet networks via an Access Controller (AC) 22 which controls one or more Access Points 24 which communicate over the air with one or more M!Ss 26. The functionality ot' wI,AN networks is generally well-known and will not be described in detail further herein.

20 In order to access (iPRS packet-switched services, a MS first performs a GPRS attach procedure with the SGSN (either a 2G GSM (iPRS attach or a 3G UMTS GPRS attach). Authentication, and location updating procedures are performed, and, if successful, the GPRS attach procedure makes the MS

available for paging via the SGSN and notification of incoming packet data.

Tlowever, to actually send and receive packet data, the MS must have an allocated Packet Data Protocol (PDP) address (eg an IP address) and must activate at least one PDP context for use with that PDP address. Each PDP 5 address for a MS may have one or more PDP contexts associated with it and data defining the PDP contexts is stored in the MS, the SGSN, and the GGSN.

I'he process of PDP context activation makes the MS known not only to the SGSN, hut also to the corresponding GGSN and inter-working with external data networks can commence.

10 PDP contexts are used to maintain state such as routing information and Quality of Service (QoS) requirements in nodes of the GPRS network. In particular, multiple PDP contexts allow one or more levels of QoS to be specified for a single PDP address oi'a MS to allow efficient transfer of a variety of data traffic, such as non real-time trat'f'ic (eg intermittent and hursty 15 data transfers. occasional transfers of large volumes of data) and real-time traffic (eg voice. video). Thus an application running on a MS with a single PDP address may utilize one or more levels of'QoS according to its needs by using one or more PDP contexts. A POP context may be in one of two states - active or inactive. When inactive. a PDP context contains no routing or 20 mapping information to process packets related to the PDP address. No data can he transferred. When active, the PDP context for the PL)P address is activated in the MS, SGSN and GGSN. The l'I)P context contains mapping

( and routing information for transferring PDP packets for that particular PDP address between the MS and the Ci(iSN.

user data is transferred between external networks and the MS using tunnelling. Between the S(iSN and the MS, tunnelling procedures are used 5 which differ between 2G GSM and 3G UMTS networks. However, between the GGSN and the SGSN, packets are tunnelled using a common encapsulation procedure according to the GPRS Tunnelling Protocol (Ci'l'P).

The packet domain PI,MN backbone network encapsulates a data packet with a GTP header, and inserts this GTP packet in a tJDP packet that is again 10 inserted in an IP packet. The IP and GTP packet headers contain the GSN addresses and tunnel endpoint identifier necessary to uniquely address a PDP context. Where there are multiple PDP contexts for a single PDP address of a MS, there must be a corresponding number ot' G'I'P tunnels established between the GGSN and the S(iSN for packet data transfer. Note the (iTP 15 tunnels used in GPRS networks are not to be confused with MIP tunnels.

When multiple PDP contexts exist for a POP address' the Ci(iSN routes downlink packets to the different G'I'P tunnels based on what are called I'raffic Flow Templates (TFTs) assigned to the PDP contexts. Each PDP context may be associated with a TFT. However, as a strict rule, at most one 20 PDP context associated with the same PDP address may exist at any time with no'I'FT assigned to it. Thus, with n multiple PDP contexts there will always be either n TFTs or (n-l) 'I'l:'l's each corresponding to individual ones of the n PDP contexts. Where there is an I to I mapping between TFTs and the GTP

( tunnels corresponding to each PDP context, selection of the GTP tunnel is straight forward on the basis of TFT. Where there is an (n- I) to n mapping, selection is also straight forward, but may involve a simple process of elimination if no match can be found for a TFT.

5 'I'l''l's are also prioritised using evaluation precedence indices. Upon reception of a data packet, the GGSN evaluates for a match, first the packet filter amongst all 'I'FTs that has the smallest evaluation precedence index and, in case no match is found, proceeds with the evaluation of packet filters in increasing, order of their evaluation precedence index. This procedure is 10 executed until a match is found, in which case the data packet is tunnelled to the SGSN via the GTP tunnel that is associated with the PDP context corresponding to the matching TT T packet filter. According to 3G IS 23.060 Clause 9.3, if no match is found, the data packet is tunnelled via the PDP context that does not have a TOT assigned to it, hut it'all T'L)P contexts have a 15 'I'F'l'assigned the (,GSN must silently discard the data packet.

I'he 'I'T:Ts contain attributes relating to the headers of downlink data packets which are used to filter the data packets and thus route or map them to the GTT' tunnel for the correct PDP context. 'I'he attributes are det'ined in terms of IP header fields. According to 3G TS 23.060 Clause 15.3.2, the data

20 packet header attributes contained in TFTs are specified in terms of both IPv4 and IPv6 header fields. Each TFT consists of between I and 8 packet filters.

each identified by a unique packet filter identifier. A packet filter also has an evaluation precedence index that is unique within all TFTs associated with the

( PDP contexts that share the same PDP address. According to 3G TS 23.060 Clause 15.3.2, each valid packet filter contains a unique identifier within a given 'I'l 'I', an evaluation precedence index that is uniquewithin all 'I'[ 'l's for one PDP address, and at least one of the following IPv4 or IPv6 packet header 5 attributes: - Source Address and Subnet Mask.

Protocol Number (IPv4) or Next Header (IPv6).

Destination Port Range. l Source Port Range.

10 - IPSec Security Parameter Index (SPI).

- Type of Service ('I'OS) (IPv4) or'l'raffic class (IPv6) and Mask.

Flow Label (IPv6).

However, not all of these may be used in combination without resulting in inconsistency. In practice, the Source Address and Suhnet Mask 15 will most commonly he used since in common use cases, a MS will establish a dif't'erent PDP context for its (or one of its) PDP addresses t'or each dit7'erent correspondent node POP address. Note that the attribute list does not contain the Destination Address attribute, only Destination Port Range. 'I'his is because 'I'F'T packet filters are not used to map packets to one of a plurality of 20 destination addresses, but to the (i'l'P tunnel corresponding to one of a plurality of PDP contexts established for a single destination address at a single MS.

( However, as discussed above, the Source Address attribute may not be sufficient for the (T(T5N to map incoming packets for downlink to the MS under certain circumstances. According to the present invention. where an MS is engaged in a communication session with a MlPv4 or MlPv6 enabled 5 MN (we shall now call the GPRS MS a CN), the procedure followed by the MN, the (,GSN, and in some embodiments the CN is modified.

First Embodiment According to a first embodiment of the present inventions where the 10 MN is IPv6 capable, the MN is modified to include its HAddr in a Hop-by Hop Options extension header of the IPv6 packet for all data packets it sends to the CN, whenever it is away from home. This applies to correspondent binding updates as well as user data packets. 'I'he existence of the IPv6 11op by-llop Options extension header is indicated by placing a zero in the IPv6 15 Next Header field of the data packet. 'I'he llop-by-llop Options extension

header then immediately follows the IPv6 header. 'I'he HAddr of the MN is included in a Type-Length-Value ('I'LV) encoded option in the Hop-by-Hop Options extension header. Thus, a suitable Options 'I'ype number (8-bits) is used to identify the type of option (ie the specification of the HAddr of the

20 MN for a packet sent to a GPRS CN) followed by the Option Data Length (which depends on the length of the IlAddr) tallowed by the Option Data itself (ie the HAddr).

In this embodiment, the GGSN is IPv6 enabled and examines the Hop by-Hop extension header of any received IPv6 packet having such a header.

Note that, the GCiSN is an intermediate node and, according to the IPv6 specification (RFC 2460), the GGSN must examine l-lop-by-flop extension

5 header. Conversely, note that according to the IPv6 specification (RFC

2460) the C',GSN must not examine any other IPv6 extension header since it is an intermediate node. Hence the MlPv6 procedure whereby a MN may send its HAddr in an IPv6 Home Address Destination Option extension header when sending a correspondent binding update will not assist in solving 10 the problem identified since it will not be visible to the G(iSN.

Furthermore, the GGSN is modified to attempt to map the IP address ot' the MN identified in an IPv6 data packet containing a 11op-by-Hop extension header to the TFT packet filters stored for l'DP contexts associated with the IlAddr of the MN, and, if a match is l'ound to transfer the data 15 packets accordingly. 'I'he CiCiSN may perform this procedure after it has flailed to map the received data packet using the standard Gl'RS procedure described above. 'I'hus, for cxamplc, using a combination of the standard and modified procedure, a data packet either having a source address matching the Source Address attribute OK having an IP address specified in a Hop-by-Hop 20 Options Header matching the Source IP Address attribute being the HAddr of the MN - will match at least those attributes ot'the TFT packet filter and will be routed to the GTP tunnel corresponding to the appropriate PDP context.

( When the data packet reached the CN, it is recognized by the CN, despite having the CoA of the MN as its source address, because it has an IPv6 Hop-by-Llop Options extension header specifying the HAddr. It may also have a Home Address Destination Option extension header specifying 5 the HAddr which will also be visible to the CN.

Second Embodiment According to the second embodiment, which is a variant of the first embodiment described above, the MN only includes its I IAddr in an Hop-by 10 Hop Options extension header of the signalling IPv6 packet it sends to the CN for correspondent binding updates. Thus, as described above, the correspondent binding update will be able to reach the CN. Upon receiving the correspondent binding update, the CN will then know the CoA of the MN and will then be able to create or modil'y a PDP context so that the GGSN 15 may route subsequent data packets sent from the MN at its CoA without need for the use of I lop-by-i lop Options extension headers. This occurs as follows: I'he C'N may modify the activated PDP context (used for a communication session with the MN) to include, in a TFT associated with the 20 PDP context. the MN's CoA - ie an IPv4 or IPv6 address - using the MS lnitiated PDP Context Modification Procedure, described in 3G TS 23.06 Clause 9.2.3 and incorporated herein by reference. I igure 4 shows the PDP context modification procedure. At step 60, the MN (not shown) performs the

i M1P correspondent binding update procedure with the CN 18 using a [Iopby Hop Options extension header as described above in the t'irst embodiment.

Assuming this is successful, at step 62, the CN send a Modify PDP Context Request to its S(iSN 14. 'I'he Modify PDP Context Request message contains 5 an instruction to add or modify a TFT associated with the Plop context to include the MN's CoA. Note that the CN may optionally also send an instruction to modify the QoS profile in the Modify PDP Context Request message. At step 64, SGSN 14 sends an Update PDP Context Request message to CiGSN 12 including the instruction to add or modify the TFT as 10 above. GCiSN 12 checks the instruction (t'or example to see if the attributes in the packet filter of the TFT form a valid combination) and if acceptable, stores or modifies the TFT for the PDP context accordingly. Then, at step 66, G(GSN 12 sends an Update PnP Context Response message to SGSN 14 indicating success. At step 68, radio access bearer modification may be 15 performed (for example in a 3(i (iPRS network in lu mode where the QoS profile of the PL)P context has changed). At step 70, S(;SN 14 sends a Modify PDP Context Accept message to the C'N to confirm the successful modification of the PDP context (i.e. the TFT).

In one alternate version of'the second embodiment, a modified TFT 20 packet filter is used in which the list of possible IPv4 or IPv6 packet header attributes that may be included in packet filter is augmented as follows: Source Address and Subnet Mask.

('are OJAddre*s.

( Protocol Number (IPv4) or Next Fleader (IPv6).

Destination Port Range.

Source Port Range.

À IPSec Security Parameter Index (SPI).

5 - Type of Service (T()S) (IPv4) or Traffic class (IPv6) and Mask.

- Flow Label (I Pv6).

where the ('are OJ'AcIdress is the IPv4 or IPv6 address of the MN in its EN.

Thus, for a POP context, TFT packet filters stored at the CN, and (iC,SN may include the CoA of the MN in a specially identil'ied field. 'I'he

10 behaviour of the Care Of Address attribute. in terms of the validity of combination with other attributes, is the same as the behaviour of the Source Address attribute (see 3G 'I'S 23.060 Clause 15.3.2). However, a TI T may comprise a packet filter having either of the Source Address and Care Of Address attributes singly or both the Source Address and Care Of Address 15 attributes in combination. In the case h1 which both attributes are specified in a single '1'1'1' packet filter, they arc treated as being alternatives - ie they are combined using the logical operator OR. Thus, a data packet either having a source address matching the Source Address attribute OR having a source address matching the Care ()f Address attribute will match at least those 20 attributes of the TF I' packet filter. The functionality of the (GUN is modified to perform matching of incoming data packets for downlink to a MS using the modified 'I'FT packet filters. Note that the same effect is achieved by

( including two packet filters in a TFT - one with the Source Address attribute defined and the other with the (tare Of Address attribute defined.

Alternatively. in a second version of the second embodiment, the standard 'I't"f packet filter attributes are used, and the MS-lnitiated PDP 5 Context Modit'ication Procedure described above with reference to Figure 4 is used to add a new or modit'y an existing TFT to add a new packet filter including the MN's Care Of Address in the standard Source Address attribute.

This new packet filter would be in addition to any existing packet filter for the I JILT. Alternatively, the packet filter may replace or modify an existing packet I O filter.

Thus, a PDP context activated for a communication session with a MN may be modified to have an associated 'I'l;'T with 1) one packet filter having both the MN's HAddr and CoA (using the augmented attribute list) or alternatively, 2) two packet filters - one having the MN's IlAddr and the 15 other the MN's CoA (using either the augmented or standard attribute list).

It will also be apparent that a PDP context may be activated together with an associated TFT packet filter including the MN's CoA using the MS lnitiatcd PDP Context Activation Procedure, described in 3(' TS 23.060 Clause 9.2.2 incorporated herein by reference. Thus, a new PDP context may 20 be activated for a communication session with the MN and, in the activation procedure, a TFT may be associated with the PDP context having either: 1) one packet filter having both the MN's HAddr and MN's CoA (using the augmented attribute list) or, alternatively, 2) two packet filters - one having

the MN's HAddr and the other the MN's CoA (using either the augmented or standard attribute list).

In this ways at'ter the initial correspondent binding update, packets sent by the MN while away from home may be filtered by the GGSN to the 5 appropriate PDP context of the C'N, without need for continued use of Hop by-Hop Options extension headers and without the processing overheads that such continued use entails.

In variants of'the first and second embodiments the MN is modified to selectively include its HAddr in an IPv6 f lop-by-Hop Options extension 10 header of the user data packet or correspondent binding update packet it sends to the CN when it (the MN) is away t'rom home. 'I'he inclusion is only performed when the MN detects that the CN is being provided service in a GPRS network. Thus, the processing overheads of' a) the MN including a Hop-by-l lop Options extension header in the tunnelled data packet, and b) the 15 intermediate nodes on the route towards the GGSN examining the flop-by Hop Options extension header are eliminated where they are not necessary.

Third F.mbodiment According to a third embodiment of the present invention, the MN 20 must always use the MIP Home Address Destination Option to include its f-lAddr when sending a correspondent binding update to the CN (described in the MlPv6 IE'I'F Draft at Clause 6.3, incorporated herein by reference). Also, a POP context with no associated 'I'FT is always established in the GPRS

network using the PDP Context Activation Procedure (described in 3C. TS 23.060 Clause 9.2.2, incorporated herein by reference). On receipt of the correspondent binding update data packet from the MN. the GGSN will attempt to match the packet to those PDP contexts with associated TETs in the 5 normal ways but when this flails because the source address is the new CoA or CoCoA of the MN, the packet will be routed to the CN using the Pl)P context with no associated 'I'L''I'. When the CN receives the correspondent binding update, it examines the Home Address Destination Option Header containing the HAddr of the MN which it reeognises. I'he MN may then associate the 10 packet with the existing communication session with the MN. The CN may then modify the existing PDP context, or create a new PDP context, to include the CoA of the MN as described above in relation to the second embodiment.

In a variant of the third embodiment, the MN is modified to selectively include its HAddr in a Home Address Destination Option I leader of a 15 correspondent binding update packet it sends to the C'N when it (the MN) is away from home. The inclusion is only pert'ormed when the MN detects that the CN is being provided service in a GI'RS network.

It will be appreciated that the embodiments described above may be implemented using data associated with the data packets other the HAddr of 20 the MN. Any data capable of uniquely identifying the MN to the CN or C,(,SN and known to the CN or GGSN prior to the MN being provided with a C'oA or CoCoA (eg known from the communication session with the MN) will do. Furthermore, it will be apparent that further data, may be included in

( the Hop-by-Hop Options extension header, and in the modified or newly created TFT to further spccit'y the MN to the CN or GGSN and to provide further filecring of received data packets by the GGSN or LPN.

It will be apparent that the present invention applies to networks other 5 than GPRS networks. In general, it applies to any network in which a gateway node may need to select one from a plurality of channels (whether PDP contexts or otherwise) for transferring downlink packets towards a node, where a user or network-side node.

Claims

Claims:

1. A method of enabling a gateway node of a first packet-switched data network to select a t'irst channel for transferring a data packet to a destination 5 packet data protocol address of a correspondent node provided service in the first network, the gateway node being arranged to select the first channel from a plurality of channels each being for transferring data packets to the destination packet data protocol address of the correspondent node, the data packet having been sent from a mobile node of a second packet-switched data 10 network external to the first network, the mobile node having been in a communication session with the correspondent node while provided service in a third packet-switched data network different to the second network, the method comprising: a) the mobile node associating, with the data packet, a first packet 15 data protocol address which it used in the communication session with the correspondent node; b) the gateway node selecting the first channel by matching the first packet data protocol address associated with the data packet received by the gateway node to a first data packet filter associated with the first channel.

2. A method according to claim 1, wherein the data packet is an Internet Protocol version 6 (IPv6) data packet and the first packet data protocol

( address of the mobile node is associated with the data packet by being included in a Hop-by-Hop extension header ot'the data packet.

3. A method according to any preceding claim comprising: 5 e) the data packet being transferred through the first channel and, in response to receipt of the data packet, the correspondent node arranging t'or the current packet data protocol address of the mobile node in the second network to be included in the first data packet filter.

10 4. A method according to claim 3, wherein the first packet filter was created, prior to step c), to enable the gateway node to select the first channel for transferring data packets sent by the mobile node while involved in the communication session, and, in step e), the first data packet filter is modified to include the current packet data protocol address of the mobile node.

5. A method according to claim 4, wherein the current packet data protocol address ot the mobile node replaces the first packet data protocol address in the first data packet filter.

20 6. A method according to claim 4, wherein the current packet data protocol address is added to the first data packet filter which also comprises the first packet data protocol address of the mobile node.

7. A method according to any of' claims 3 to 6, wherein, the first packet filter is newly created in step c).

8. A method according to any preceding claim, wherein mobility of the 5 mobile node between networks or subnetworks is supported using the Mobile Internet Protocol (MIP) standards, the current packet data protocol address of mobile node is the Care Of Address (CoA, CoCoA) of the mobile node, and the first packet data protocol address of the mobile node is the Home Address (HAddr) of the mobile node.

9. A method according to claim 8, wherein the data packet is a MIP correspondent binding update sent Prom the mobile node to the correspondent node. 15 10. A method according to any preceding claim, wherein the first network conforms to the General Packet Radio Service (GPRS) standards and the l plurality of channels correspond to a plurality of packet data protocol contexts | in the first network. | 20 11. A gateway node of a first packet-switched data network arranged to select a first channel, for transferring a data packet to a destination packet data protocol address of a correspondent node provided service in the first network, from a plurality of channels each being for transferring data packets

( to the destination packet data protocol address of the correspondent node, the data packet having been sent from a mobile node of a second packet-switched data network external to the first network, the mobile node having been in a communication session with the correspondent node while provided service in S a third packet-switched data network different to the second network, wherein: the gateway node selects the first channel by matching a first packet data protocol address, associated with the data packet received by the gateway node, to a first data packet filter associated with the first channel, the first 10 packet data protocol address having been used by the mobile node in the communication session with the correspondent node.

12. A gateway node according to claim 11, wherein the data packet is an Internet Protocol version 6 (IPv6) data packet and the first packet data 15 protocol address of' the mobile node is associated with the data packet by being included in a I lop-by-l lop extension header of the data packet.

13. A gateway node according to any claim I I or claim 12 wherein, after having sent the data packet to the correspondent node, and in response to 20 receipt of a subsequent instruction from the correspondent node, the gateway node includes, in the first data packet filter, the current packet data protocol address of the mobile node in the second network.

( 14. A gateway node according to claim 13, wherein the first packet filter was created to enable the gateway node to select the first channel t'or transferring data packets sent by the mobile node while involved in the communication session, and the first data packet filter is modified to include 5 the current packet data protocol address of the mobile node.

15. A gateway node according to claim 14, wherein the current packet data protocol address of the mobile node replaces the first packet data protocol address in the first data packet filter.

16. A gateway node according to claim 14, wherein the current packet data protocol address is added to the first data packet filter which also comprises the first packet data protocol address of the mobile node.

15 17. A gateway node according to any of'claims 13 to 16. wherein, the first packet filter is newly created.

18. A gateway node according to any of claims I I to 17, wherein mobility of the mobile node between networks or subnetworks is supported using the 20 Mobile Internet Protocol (MIP) standards, the current packet data protocol address of mobile node is the Care Of Address (CoA, CoCoA) of the mobile node, and the first packet data protocol address of the mobile node is the Home Address (I lAddr) of the mobile node.

19. A gateway node according to claim 18. wherein the data packet is a MIP correspondent binding update sent from the mobile node to the correspondent node.

2(). A gateway node according to any of claims 11 to 19, wherein the first network conforms to the General Packet Radio Service (GPRS) standards and the plurality of channels correspond to a plurality of packet data protocol contexts in the first network.

21. A mobile node of a second packet-switched data network arranged to enable a gateway node of first packet-switched data network, different to the second network, to select a first channel for transt'erring a data packet sent from the mobile node to a destination packet data protocol address of a 15 correspondent node provided service in the t'irst network, the gateway node being arranged to select the first channel from a plurality of channels each being for transferring data packets to the destination packet data protocol address of the correspondent node, the mobile node having been in a communication session with the correspondent node while provided service in 20 a third packet-switched data network different to the second network, wherein: the mobile node associates, with the data packet, a first packet data protocol address which it used in the communication session with the

( correspondent node, the first packet data protocol address being for use by the gateway node in selecting the first channel by matching the first packet data protocol address associated with the data packet received by the gateway node to a first data packet filter associated with the first channel.

22. A mobile node according to claim 21, wherein the data packet is an Internet Protocol version 6 (IPv6) data packet and the first packet data protocol address of the mobile node is associated with the data packet by being included in a Hop-by-Hop extension header of' the data packet.

23. A mobile node according to claim 21 or 22, wherein mobility of the mobile node between networks or subnetworks is supported using the Mobile Internet Protocol (MIP) standards, the current packet data protocol address of mobile node is the C'are Of Address (C'oA. ('o('oA) of the mobile node, and 15 the first packet data protocol address of the mobile node is the Home Address (HAddr) of the mobile node.

24. A mobile node according to claim 23 wherein the data packet is a MIP correspondent binding update sent from the mobile node to the 20 correspondent node.

25. A mobile node according to any of claims 21 to 24, wherein the first network conforms to the (ieneral Packet Radio Service (GPRS) standards and

! the plurality of channels correspond to a plurality of packet data protocol contexts in the first network.

26. A method of enabling a gateway node of a t'irst paeket-switehed data 5 network to select a first channel for transferring a data packet to a destination packet data protocol address of a correspondent node provided service in the first network. the gateway node being arranged to select the first channel from a plurality of channels each being t'or transferring data packets to the destination packet data protocol address of the correspondent node, the data 10 packet having been sent from a mobile node of a second packet-switched data network external to the first network, the mobile node having been in a communication session with the correspondent node while provided service in a third packet- switched data network different to the second network, wherein mobility of the mobile node between networks or subnetworks is supported 15 using the Mobile Internet Protocol (MIP) standards. the mobile node having a home packet data protocol address (HAddr) in the third network, the mobile node having moved to the second network and having been provided with a current packet data protocol address (CoA, CoCoA) in the second network, the method comprising: 20 a) the mobile node sending a MIP correspondent binding update packet addressed to the correspondent node, the MIP correspondent binding update packet having the home packet data protocol address of the mobile node associated with it;

( b) the gateway node receiving the correspondent binding update packet and transferring it to the correspondent node using a second channel having no associated data packet filters; c) the correspondent node match the home packet data protocol 5 address of the mobile node associated with the correspondent binding update packet to the communication session with the mobile node; and d) in response to the matching, the correspondent node arranging Or the current packet data protocol address of the mobile node to be included in the first data packet filter.

27. A method according to claim 26, wherein the home packet data protocol address of the mobile node is associated with the correspondent binding update data packet by being included in a Home Destination Option extension header ot the correspondent binding update data packet.

r 28. A method according to claim 26 or claim 27, wherein the first packet filter was created. prior to step d), to enable the gateway node to select the first channel tor transferring data packets sent by the mobile node while involved in the communication session, and, in step d), the first data packet 20 filter is modified to include the current packet data protocol address of the mobile node.

( 29. A method according to claim 28, wherein the current packet data protocol address of the mobile node replaces the home packet data protocol address in the first data packet filter.

5 30. A method according to claim 28, wherein the current packet data protocol address is added to the first data packet filter which also comprises the home packet data protocol address of the mobile node.

31. A method according to claim 26 or claim 27, wherein, the first packet 10 filter is newly created in step d).

32. A method according to any of claims 26 to 31, wherein the first network conforms to the General Packet Radio Service (GPRS) standards and the plurality of channels correspond to a plurality of packet data protocol 15 contexts in the first network.

33. A correspondent node of a first packet-switched data network arranged to select a first channel, for transferring a data packet to a destination packet data protocol address of a correspondent node provided service in the first 20 network, Prom a plurality of channels each being for transferring data packets to the destination packet data protocol address of the correspondent node, the data packet having been sent from a mobile node of a second packet-switched data network external to the first network, the mobile node having been in a

( communication session with the correspondent node while provided service in a third packet-switched data network different to the second network' wherein mobility of the mobile node between networks or subnetworks is supported using the Mobile Internet Protocol (Mll3) standards' the mobile node having a 5 home packet data protocol address (llAddr) in the third network the mobile node having moved to the second network and having been provided with a current packet data protocol address (C'oA, CoC'oA) in the second network, wherein: a) the correspondent node receives a MIP correspondent binding 10 update packet transferred from the gateway node through a second channel having no associated data packet filters, the MIP correspondent binding update packet having the home packet data protocol address of the mobile node associated with it; b) the correspondent node matches the home packet data protocol 15 address of the mobile node associated with the correspondent binding update packet to the communication session with the mobile node; and c) in response to the matching, the correspondent node arranges for the current packet data protocol address of the mobile node to be included in the lost data packet filter.

34. A correspondent node according to claim 33' wherein the home packet data protocol address of the mobile node is associated with the correspondent

( binding update data packet by being included in a Tlome Destination Option extension header of the correspondent binding update data packet.

35. A correspondent node according to claim 33 or claim 34, wherein the 5 first packet filter was created to enable the gateway node to select the first channel t'or transferring data packets sent by the mobile node while involved in the communication session, and the first data packet filter is modified to include the current packet data protocol address ot'the mobile node.

10 36. A correspondent node according to claim 35, wherein the current packet data protocol address ot' the mobile node replaces the home packet data protocol address in the first data packet filter.

37. A correspondent node to claim 35, wherein the current packet data 15 protocol address is added to the first data packet filter which also comprises the home packet data protocol address ot'the mobile node.

38. A correspondent node according to claim 33 or claim 34, wherein the t'irst packet filter is newly created.

39. A correspondent node according to any of claims 33 to 38, wherein the first network conforms to the General Packet Radio Service (GPRS) standards

( and the plurality of channels correspond to a plurality of packet data protocol contexts in the first network.