GB2398206A

GB2398206A - Multicast Routing in a Packet Radio Network

Info

Publication number: GB2398206A
Application number: GB0302776A
Authority: GB
Inventors: Robert Michael Rummler; Yun Won Chung; Abdol Hamid Aghvami
Original assignee: Kings College London
Current assignee: Kings College London
Priority date: 2003-02-06
Filing date: 2003-02-06
Publication date: 2004-08-11
Also published as: GB0302776D0

Abstract

In a packet radio network (1) comprising a radio access network (5) and a core network CN (2) via which a plurality of mobile nodes may communicate over a wireless link with an external packet data network (8), a method of forwarding multicast packet data units (M-PDUs) for a multicast group to at least one subscriber mobile node (12) subscribed to the multicast group, which method comprises the steps of: <SL> <LI>(1) receiving an M-PDU at a first node (3) in said CN (2); <LI>(2) identifying at least one second node (4) responsible for said at least one subscriber mobile node; and <LI>(3) where a second node (4) serves multiple subscriber mobile nodes, forwarding said M-PDU from the first node (3) to the or each second node (4) via a number of multicast logical links (11) that is less than the number of subscriber mobile nodes (12) of the multicast group served by each second node (4) respectively. </SL>

Description

METHOD, NETWORK NODE AND COMPUTER PROGRAM FOR

MULTICAST ROUTING IN A PACKET RADIO NETWORK

FIELD OF THE INVENTION

The present invention relates to a method of forwarding multicast packet data units, to a network node for use in such a method, to a computer program for executing the method and to a product comprising the computer program.

lo BACKGROUND OF THE INVENTION

Mobile communications systems are generally any telecommunications system that enables wireless communication by users with mobile devices (or nodes), moving or stationary, in the service area of the system. Often the mobile communications network is an access network providing a user with wireless access to external networks, hosts, or services offered by specific service providers. Mobile devices include cellular phones, personal digital assistants (PDAs), notebook computers and digital cameras for example.

The Universal Mobile Communications System ("UMTS") is presently being developed as a member of the global family of third generation ("3G") mobile technologies identified by the International Telecommunications Union (ITU) . The UMTS architecture comprises a UMTS terrestrial radio access network (UTRAN) and a backbone core network (CN), which together provides a bearer network. The UTRAN provides the radio interface and the physical radio resources for user equipment (UE). The UTRAN is connected to the CN that provides various telecommunications services such as data, speech and messaging services. The CN may be a circuit-switched (CS) domain network or a packet-switched (PS) domain network. The PS backbone network will provide the UE with Internet Protocol (IP) connectivity services. Thus the UE can establish an IP connection to any IP host, IP network or 1P service via the 3G access network.

The UMTS CN infrastructure comprises support nodes such as the gateway GPRS support node (GGSN) and serving GPRS support node (SGSN).A SGSNis connected to the UTRANso that the SGSN can provide a packet service for mobile UE. The UTRAN provides radio access and packet-switched data transmission between the SGSN and UK. The CN is in turn connected to an external data network, for example to a public switched packet data network PSPDN via the GGSN. The UMTS service thus allows packet-switched data transmission to be provided between mobile nodes and external data networks while the UTRAN provides radio access over a wireless link.

The main functions of the SGSN are to detect new mobile stations in its service area, handle the process of registering new UEs, send/receive data packets lo to/from the UEs, and to keep a record of the location of the UEs inside its service area. In order to access the UMTS services, a UE first makes its presence known to the network by performing the PS attach procedure. This operation establishes a mobility management context as well as a routing context at the UE and the SGSN.

The MM context of the SGSN may contain subscriber data such as the subscriber identity, location information etc. The main functions of the GGSN involve interaction with the external data networks. The GGSN may also be connected directly to a private corporate network or host for example. The GGSN includes PDP addresses and routing information i.e. SGSN addresses for active subscribers. The GGSN updates the location directory using routing information supplied by the SGSNs. The GGSN uses the routing information for tunnelling the protocol data units (PDUs) from the external networks to the current location of the UE i.e. to the serving SGSN. The tunnelling means that the packet data is encapsulated into another data packet during transfer from one end of the tunnel to another. The GGSN also decapsulates data packets from UEs and forwards them to the appropriate data network. In order to send and receive data, the UE activates the packet data address that it wants to use by requesting a "PDP activation procedure". This operation makes the UE known in the corresponding GGSN, and internetworking with other networks can commence. More particularly, one or more PDP context is created in the UK, GGSN and SGSN and stored in the serving SGSN in connection with MM context. The PDP context defines different data transmission parameters, such as PDP type (e.g. PPP or IF), PDP address (e.g. IP address) and quality of service (QoS). Two associated PDP contexts in different GSNs are used as endpoint records for a GTP tunnel. The tunnel is identified with a Tunnel Endpoint IL) (TEID). The UE activates the PDP context with a specific - 3 message, Activate PDP Context Request, in which it gives information on the PDP type, PDP address and required QoS, and optionally the access point name APN. The SGSN sends a create PDP context message to the GGSN which creates the PDP context and sends it to the SGSN. The SGSN sends the PDP context further to the UE in an Activate PDP Context Response message, and a virtual connection or logical link between the UE and the GGSN is established. The PDP context is stored in the UK, the SGSN and the GGSN. As a result the SGSN tunnels all the data packets from the UE to the GGSN, and the GGSN tunnels to the SGSN all data packets received from the external network and addressed to the UK.

The exact way in which a UMTS network will be deployed will be decided by the network operator. However, it is generally envisaged that a GGSN will be connected to the Internet at large, in a similar way to a Local Area Network (LAN) for examples thereby giving mobile users access to the Internet. It is expected that a GGSN may support of the order of approximately 200,000 active connections; a SGSN may support of the order of 50,000 active connections and a RNC may support of the order of hundreds of base stations, e.g. l 50 to 550.

Hosts frequently demand transmission of the same data on the same downlink. For example, businessmen at a conference may all require simultaneous access to a webcast, videoconference, files, stock quotes, Internet audio and multimedia from their respective mobile terminals. Other groups of hosts may require simultaneous access to details of sports events for example, as they happen in real time. Packet data to each of these groups may be sent to each user in the group with unicast messages. For example, if ten businessmen in a hotel wish to view a live webcast, the packet data of the webcast can be sent ten times from the Internet host in total. This is clearly inefficient in terms of network resources.

Multicast or group communication protocols have been designed for packet switched networks to overcome this problem by supporting point-tomultipoint data transfer. Multicasting can be defined as a one-to-many (or many-to-many) type of communication, i.e. the transmission of the same information from one or multiple senders to several destinations. With multicasting, a sender's data stream is transmitted only once on links that are shared along the paths to a targeted set of destinations. This data stream is duplicated at the points (e.g. routers for IP networks) - 4 where the paths diverge in order to reach receivers located on different networks or sub-networks. Multicasting offers efficient multi-destination delivery since data is transmitted in an optimal manner with minimal packet duplication.

s The most widely deployed multicast protocol in use today is Internet Protocol (IP) multicast. IP is the protocol by which data is sent from one computer to another on the Internet. Both IP version 4 (IPv4) and IP version 6 (IPv6) provide inbuilt support for point-to-multipoint or multicast connections. IP multicasting is defined as the transmission of an IP datagram to a 'host group", a set of zero or more hosts lo identified by a single IP destination address. The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group, but membership in a group may be restricted to only those hosts possessing a private access key. A host may be a member of more than one group at a time. A host need not be a member of a group to I S send datagrams to it (see RFC 1 112).

For example the IP multicast protocol would permit, in the example above, only one transmission of the webcast packet data over the Internet until the last router where the packets would be copied and sent to each of the ten users.

Fundamental to all multicasting protocol is the concept of a process (i.e. an application associated with a host) joining a multicast group. The Internet Group Management Protocol (lGMP) (RFC 2236) and Multicast Listener Discovery (MLD) (RFC 2710) are protocols for 1P Version 4 (IPv4) and IP Version 6 (IPv6) 2s respectively that allow a host to inform its local router that it wishes to receive transmissions addressed to a specific multicast group. IGMP and MLD run between hosts and neighbouring multicast routers. Based on the group membership information learned from IGMP or MLD, a router is able to determine which (if any) multicast traffic needs to be forwarded to each of its "leaf'' sub-networks (i.e. the sub networks that have no further downstream routers). A multicast routing protocol is executed on routers to construct packet delivery paths and to accomplish packet forwarding to the multicast recipients. IGMP is considered part of the IP layer. IGMP messages are transmitted in IPv4 datagrams.

The functionality of IGMP is based on report and query messages that are s- exchanged between hosts and their neighbouring routers. When a host on a given interface (i.e. a sub-network) wants to join a multicast group, the host sends an IGMP report to the neighbouring multicast router. A multicast router sends an IGMP query at regular intervals to see if hosts still have processes belonging to any groups.

Applying either the IGMP or the MLD protocol to UMTS networks results in inefficient multicast routing and group management. The principle disadvantage is that network-layer routing (i.e. selecting the transmission path for the "next hop" in the route) within the UMTS network is not based on the evaluation of IP headers and 0 is therefore not IP-based. UMTS network-layer routing is implemented by encapsulating and subsequently tunnelling IP packets between network nodes. In encapsulating IP packets, a new header containing tunnelling information is added to the packet, thus effectively rendering the initial IP header "invisible" to the UMTS network. Only at the network gateway (GGSN) is the actual IP header processed for the purpose of packet exchange with external networks. Bearing in mind that IGMP messages are encapsulated in IP packets and therefore cannot be processed by intermediate UMTS network nodes, IGMP or MLD messages must traverse the entire network until they reach the network gateway before any action in response to the join/leave request can be taken. This is clearly inefficient.

Furthermore, the use of tunnels between UMTS network nodes does not lend itself toward resource-efEcient multicast message delivery as each individual tunnel established between the respective network nodes maps to a single subscriber within the network in a one-to-one relationship. Applying the tunnelling mechanism for one to-many message delivery *om a single source to a group of m subscribers in the downlink direction is equivalent to m times unicast. Therefore m duplicates of the multicast messages are transmitted across the UMTS network since the multicast address is "hidden" by the GTP (GPRS Tunnelling Protocol) headers used by the UMTS network nodes.

"IP Multicast in UMTS" by M. Hauge and O. Kure (see www.unik. no/mariannh/Artikler/IP%20Multicast%20in%20UMTS.pdf) discloses UMTS architecture in which the RNC acts as the terminating node for the IP multicast protocol. It is suggested that multicast data will be forwarded using multicast data distribution in the Core Network and unicast data distribution from the - 6 RNC to each UMTS multicast subscriber. However, it is not apparent from this document how the logical link between the GGSN and RNC will be handled. Packets arriving at the GGSN must be associated with a PDP context, otherwise they are silently discarded. Since PDP contexts are only associated with a single user, it is not clear how multicast packets arriving at the GGSN will be handled.

WO 00/57601 discloses a method for forwarding a multicast message received from an external data network (PDN) to subscribers of a packet radio network. Subscriber-specific information defining multicast messages to be received l o by the subscribers is stored in the GGSN. Based on this subscriber-specific information, a point-to-point connection is established between each subscriber and the GGSN for delivery of multicast messages. This enables PDUs addressed to a multicast address to be delivered to subscribers over the packet radio network.

However, a multicast packet must be duplicated at the GGSN for each multicast subscriber. Thus no saving is made on bandwidth over the packet radio network, even though there may be several subscribers to the same multicast group served by the same SGSN.

WO 02/51072 discloses an IP-based group communication procedure based on pre-established logical connections between a GGSN and members of a group in a UMTS network. PDP contexts of the members of a group are associated and stored at the GGSN.VolP data addressed to the multicast address of the group is sent by one member to a multicast router on an external PDN, via that member's PDP context.

The multicast router forwards the VolP packets to the members of the group. The multicast packets are received by the GGSN that maps the multicast address to the PDP contexts of the members of the group. The GGSN then sends copies of the VolP packets to each member of the group (apart from the sending member) through their respective logical connections. Thus it is apparent that in this method packets are copied at the GGSN and no benefits of a multicast transmission protocol are realised over the UMTS network.

From the foregoing it is apparent that there is a need for an improved UMTS network that supports point-to-multipoint or multicast message delivery. There is also a need for such a network where the same or similar benefits of a multicast protocol on a PDN are obtained, at least partly, on a packet radio network.

V

Y - 7

There is yet further a need for a packet radio network that supports IPbased multicast protocols but that does not necessarily need to implement IP-based multicast group management protocols such as IGMP or MLD. s

SUMMARY OF THE PRESENT INVENTION

Multicast Routing 0 Preferred embodiments of the present invention aim to provide support for multicast at the packet radio layer, thereby reducing the amount of processing necessary by nodes in the network. The present invention aims to reduce the amount of processing of multicast join or leave messages and therefore offers improved performance over alternative solutions based on IGMP. Preferred embodiments of the invention provides a mechanism for overcoming this inherent lack of support for resourceefficient multicast message delivery by establishing tunnels across the Gn and lu interfaces that map to a multicast group (i.e. a plurality of subscribers) instead of to a single subscriber, thereby avoiding duplicate transmissions of multicast messages across the Gn and lu interfaces of the network.

The present invention includes a method of multicast routing for a packet radio network, and more particularly but not exclusively a UNITS network. Preferred embodiments of the present invention employ new multicast routing procedures at the packet radio layer or PDP layer that lies above the UDP/IP layer in the packet radio network. Thus nodes in the packet radio network do not need to use IGMP, MLD or any other IP multicast group management protocols in order to handle multicast traffic arriving from external packet data networks.

According to the present invention there is provided, in a packet radio network comprising a radio access network (RAN) and a core network (CN) via which a plurality of mobile nodes may communicate over a wireless link with an external packet data network, a method of forwarding multicast packet data units (M PDUs) for a multicast group to at least one subscriber mobile node subscribed to the multicast group, which method comprises the steps of: (1) receiving an M-PDU at a first node (ANGST) in said CN; - 8 (2) identifying at least one second node (SGSN) responsible for said at least one subscriber mobile node; and (3) where a second node (SGSN) serves multiple subscriber mobile nodes, forwarding said M-PDU from the first node (GGSN) to the or each second node (SGSN) via a number of multicast logical links that is less than the number of subscriber mobile nodes of the multicast group served by each second node (SGSN) respectively. There may be a number of multicast logical links per SGSN. For example, the number of multicast logical links between the GGSN and each SGSN may equate to differing qualities of service. Where the first node is a GGSN, the M o PDU is a multicast packet, for example an IF multicast packet received from the Internet. Accordingly whilst the term multicast packet data unit (M-PDU) is primarily intended to cover multicast packets transmitted over a packet radio network, it may also include IP multicast packets per se. the multicast logical links may be M-PDP contexts and/or M-RAB contexts as defined herein.

Preferably, said M-PDU is forwarded to the or each second node (SGSN) responsible for said at least one subscriber mobile node via a single multicast logical link per second node (SGSN). This helps to reduce network resources consumed by multicast traffic. In particular, multicast packets need only be sent once on each multicast logical link and in total a number of times equivalent to the number of SGSNs serving subscribers to the multicast group. This is in contrast to existing support for multicast in packet radio networks in which the multicast packet must be replicated at the GGSN for each user that is subscribed to the group.

Clearly there may arise occasions where there is only one subscriber to a multicast group per SGSN. In this scenario the invention provides a dedicated logical link for multicast packets for that subscriber. However, as soon as there are a plurality of subscribers to one multicast group that are served by the same SGSN, multicast packets for that group may be forwarded from the GGSN to that SGSN over a number of logical links that is less than the number of subscribers. In one embodiment, there is only one logical link that provides a dedicated multicast logical link such that, no matter how many subscribers join the multicast group, the M-PDU need only be transmitted once over the dedicated link of those subscribers.

Advantageously, the method further comprises the steps of, at the or each _ 9 _ second node (SGSN), identifying at least one third node (RNC) responsible for said at least one subscriber mobile node, and where a third node (RNC) serves multiple subscriber mobile nodes, forwarding said M-PDU from the second node (SGSN) to the or each third node (RNC) via a number of multicast logical links that is less than the number of subscriber mobile nodes of the multicast group served by each third node (RNC) respectively. This has the same advantages as for the link between the first node (GGSN) and the or each SGSN as described above in that less network capacity is consumed by multicast traffic. In UMTS there will be two multicast logical links, one between the GGSN and SGSN and the other between the SGSN lo and the RNC. As used herein the term "multicast logical link" is intended to cover a link comprising one or a number of segments.

In one embodiment, said M-PDU is forwarded to the or each third node (RNC) responsible for said at least one subscriber mobile node via a single multicast logical link per third node (RNC).

Preferably, the method further comprises the steps, upon receipt of said M PDU at the first node (GGSN), of searching a database for records of multicast logical links maintained by the first node (GGSN) for a record that references the multicast address of said M-PDU. In this way, multicast traffic can be associated quickly with the dedicated multicast logical link. The search may be performed on the basis of the IP multicast address of the incoming packet for example.

Advantageously, each record contains a list of multicast subscriber entries for a particular multicast group, each multicast subscriber entry containing a reference to a first active logical link associated with the subscriber mobile node of that entry, and wherein said reference is used to look up the first active logical link for each multicast subscriber entry and extract the identity of the responsible second node (SGSN). By making reference (for example with a pointer) to the individual logical link of each subscriber, network resources are saved as the record does not have to store mobility parameters or be update after inter-SGSN handover. Each time the first active logical link is looked up, the record returns the most up to date SGSN for that subscriber.

Preferably, said reference comprises the Network Service Access Point (NSAPI) and/or International Mobile Subscriber Identity (IMSI) and/or Tunnel Endpoint Identifier (TEID), and said first active logical link comprises the PDP context associated with said subscriber mobile node between the first node (GGSN) and the responsible second node (SGSN). In this way, the existing logical links that must be established for each mobile node to communicate over the packet radio network are utilised.

Advantageously, the method further comprises the steps of creating a list containing the identity of the or each second node (SGSN) responsible for said at lo least one subscriber mobile node, removing duplicate identities from said list, and replicating and forwarding said M-PDU to the or each second node (SGSN) remaining on the list. In this way multicast traffic need only be transmitted once or a small number of times over each multicast logical link.

Preferably, a GGSN multicast identifier is used to encapsulate said M-PDU and forward it to the or each responsible second node (SGSN), and each multicast logical link is associated with one of said records. Thus, each multicast group has an identifier and logical link at the packet radio layer (or GTP layer in the case of UMTS). The GGSN multicast identifier may be set arbitrarily so long as the so receiving node is able to resolve different multicast logical links on the basis thereof.

In one embodiment, the GGSN identifier is set by the receiving endpoint of the multicast logical link i.e. the SGSN for the Gn interface.

In one embodiment, said GGSN multicast identifier comprises a first Multicast-Tunnel Endpoint Identifier (M-TETD) calculated from the multicast address of the M-PDU, and said record is a multicast PDP (M-PDP) context. The first M TEID may be set equal to the IP multicast address in IPv4. For IPv6 multicast addresses that are 128-bits long and are therefore too big to be held in the first M TEID field, the first M-TEID may be set arbitrarily by the SGSN. This may be done, for example, with a hashing function that hashes the 1 28-bit field to a size that fits the

first M- l'EID field.

Advantageously, the method further comprises the steps, upon receipt of said M-PDU the or each second node (SGSN), of searching a database for records of multicast logical links maintained by the second node (SGSN) with the first node (GGSN) for a record associated with said M-PDU.

Preferably, said search is performed using the GGSN multicast identifier (or first M-TEID) associated with the M-PDU.

Advantageously, each record contains a list of multicast subscriber entries for a particular multicast group, each multicast subscriber entry containing a reference to a second active logical link associated with the subscriber mobile node of that entry, and wherein said reference is used to look up the second active logical link for each lo multicast subscriber entry and extract the identity of the responsible third node (RNC), and to look up a mobility management record for the subscriber mobile node.

Preferably, said reference comprises a Transaction Identifier (Tl) and/or International Mobile Subscriber Identity (IMSI) of the subscriber mobile node, and said second active logical link comprises the PDP context associated with said subscriber mobile node between the second node (SGSN) and the responsible third node (RNC).

Advantageously, the method further comprises the step of establishing a connection in the packet switched domain if the mobility management record indicates that the subscriber mobile node is not connected in that domain.

Preferably the method further comprises the steps of creating a list containing the identity of the or each third node (RNC) responsible for said at least one subscriber mobile node, removing duplicate identities from said list and replicating and forwarding said M-PDU to the or each RNC remaining on the list.

Advantageously, an SGSN multicast identifier is used to encapsulate said M PDU and forward it to the or each responsible third node (RNC), and the or each multicast logical link is associated with said record. The SGSN multicast identifier may be set arbitrarily so long as the receiving node is able to resolve different multicast logical links on the basis thereof. In one embodiment, the SGSN identifier is set by the receiving endpoint of the multicast logical link i.e. the RNC for the lu interface. - 12

Preferably, said SGSN multicast identifier comprises a second Multicast Tunnel Endpoint Identifier (second M-TELID) calculated from the multicast address of the M-PDU, and said record is a multicast PDP (M-PDP) context. The second M TEID may be set equal to the IP multicast address in IPv4. For IPv6 multicast s addresses that are 128-bits long and are therefore too big to be held in the second M TEID field, the second M-TEID may be set arbitrarily by the RNC. This may be done, for example, with a hashing function that hashes the 128-bit field to a size that

fits the second M-TEID field.

lo Advantageously, the method further comprises the steps, upon receipt of said M-PDU the or each third node (RNC), of searching a database for records of multicast logical links maintained by the third node (RNC) with the second node (SGSN) for a record associated with said M-PDU.

Preferably, said search is performed using the SCiSN multicast identifier (or second M-TEID) associated with the M-PDU.

Advantageously, each record contains a list of multicast subscriber entries for a particular multicast group, each multicast subscriber entry containing a reference to a third active logical link associated with the subscriber mobile node of that entry, and wherein said reference is used to look up the third active logical link for each multicast subscriber entry and extract the identity thereof.

In one embodiment said reference comprises a radio access bearer (FLAB) ID and/or IMSI and said third active logical link is an RAB context, the method further comprising the steps of replicating said M-PDU and forwarding to said subscriber mobile node over the wireless link.

In another embodiment the individual PDP and RAB contexts that are used for multicast message forwarding maintain an additional field storing an identifier of the M-PDP or M-RAB context they are associated with.

According to another aspect of the present invention there is provided a network node for use in a packet radio network, which network node comprises means for storing and executing computer executable instructions for performing a - 13 method or part of a method as set out above. The network node may be a GGSN, SGSN, RNC or any hierarchical equivalents.

According to another aspect of the present invention there is provided a s network node for use in a packet radio network, which network node comprises means for storing and executing computer executable instructionsfor performing either: ( I) any of the first node (GGSN) method steps as set out above; or (2) any of the second node (SGSN) method steps as set out above; or l o (3) any of the third node (RNC) method steps as set out above.

According to another aspect of the present invention there is provided a computer program comprising computer executable instructions for causing a computer to perform the first node (GGSN) method steps as set out above; second node (SGSN) method steps as set out above; and/or any of the third node (RNC) method steps as set out above.

The computer program may be embodied on a record medium, stored in a computer memory, embodied in a read-only memory or carried on an electrical carrier signal. The program or any part thereof may be downloaded from one node, external or internal to the packet radio network, to one or more of the nodes on the UMTS network. This is advantageous as no hardware changes need to be made to any of the UMTS network nodes.

2s Multicast Group Management T he present invention includes a method of multicast group management for a packet radio network, and more particularly but not exclusively a UMTS network.

Preferred embodiments of the present invention employ new multicast routing procedures at the packet radio layer or PDP layer that lies above the UDP/IP layer in the packet radio network. Thus nodes in the packet radio network do not need to use IGMP, MLD or any other IP multicast group management protocols in order to handle multicast traffic arriving from external packet data networks.

3s According to another aspect of the present invention there is provided, in a - 14 packet radio network comprising a radio access network (RAN) and a core network (CN) via which a plurality of mobile nodes may communicate over a wireless link with an external packet data network, a method of administering at least one multicast group, subscribers of which are from said plurality of mobile nodes, which method comprises the steps of: ( 1) maintaining a first database of subscribers of each multicast group at a first node (GGSN) in said packet radio network, said database enabling identification of the or each second node (SGSN), or any other network node on the packet radio network, responsible for the subscribers of each multicast group; lo (2) providing a mapping between subscribers of each multicast group and a number of multicast logical links between the first node (GGSN) and the or each second node (SGSN); wherein, where there is more than one subscriber of a multicast group served by a second node (SGSN), the first database maps those subscribers to a number of multicast logical links that is less than the number of those subscribers. In this way the number of times a multicast packet needs to be sent over a packet radio network can be reduced as subscribers in each group are managed and associated with only one or a small number of dedicated multicast logical links. The mapping of the subscribers of a multicast group to a number of multicast logical links may be provided by associating the IP address of the multicast group with the number of multicast logical links for example. The multicast logical links may be the M-PDP contexts and/or M-RAB contexts defined herein.

In one embodiment, for each multicast group, said database maps subscribers thereof to a single multicast logical link per second serving node (SGSN).

Preferably, identification of the or each second node (SGSN) is by means of a pointer for each subscriber in said database, each pointer referencing an individual logical link for a subscriber.

In one embodiment each individual logical link is a PDP context that identifies the second node (SGSN) serving that subscriber.

Advantageously, said multicast logical link is at the PDP layer of the packet data network. By managing subscribers of multicast groups at the packet radio layer, - 15 e.g. the GTP layer that is above the U1)P/IP layer in the packet radio network, nodes do not need to implement specific group management protocols designed for the network layer. Thus they are able to use the existing infrastructure, reducing the processing overhead on the network.

Preferably, the method further comprises the steps of: (1) maintaining a second database of subscribers of each multicast group at the second node (SGSN) in said packet radio network, said database enabling identification of one or more third nodes (RNC) responsible for the subscribers of lo each multicast group; (2) providing a mapping between subscribers of each multicast group and a number of multicast logical links between the second node (SGSN) and the or each third node (RNC); wherein, where there is more than one subscriber of a multicast group served is by a second node (SGSN), the second database maps those subscribers to a number of multicast logical links that is less than the number of those subscribers. The mapping of subscribers of a multicast group and a number of multicast logical links may be by associating a first multicast identifier (first M-TEID) with those links. The first multicast identifier may be configured by the second node (SGSN) during set up of the multicast logical links for that group. The second node (SGSN) may inform the first node (GGSN) of the first multicast identifier that it should use in forwarding multicast packets that it receives.

Advantageously, the method further comprises the steps of maintaining a as third database of subscribers of each multicast group at a third node (RNC) in said packet radio network, said third database enabling identification of the or each fourth node (Node B), or any other network node on the packet radio network, responsible for the subscribers of each multicast group; wherein said third node duplicates multicast data packets according to the number of users served by the or each fourth node (Node B) and forwards them on to a radio access bearer for transmission over a wireless link.

Preferably, if a user of a mobile node wishes to subscribe to a multicast group, the mobile node sends a join request message over its individual logical link to 3s the packet radio network so as to cause the first, second and/or third nodes to add that mobile node to their databases such that multicast packets arriving subsequently at the first node (GGSN) are forwarded to said mobile node over said number of multicast logical links to its serving second node (SGSN).

In one embodiment said join request message is sent firstly to the mobile node's serving node (SGSN) in the packet radio network.

Advantageously, wherein if said first, second and/or third node does not include an entry for the multicast group that the mobile node wishes to join, the lo method further comprises the steps of establishing a multicast logical link between the core network (CN) and the radio access network (RAN), and causing multicast messages to be forwarded from the external packet data network to the first node (GGSN) of the packet radio network. If a multicast logical link needs to be created, the network may also configure and/or assign a first and/or second multicast identifier (first M-TEID and second M-TEID) to the multicast logical link and then inform the other nodes of the first identifier. The configuring may be done by the SGSN and/or RNC for the Gn (first M-TE1D) and Iu (second M-TEID) interfaces respectively.

Preferably, the step of establishing a multicast logical link comprises the steps of: (1) creating a multicast logical link entry in a database at the second node (SGSN) of the mobile node and adding details of the mobile node thereto; (2) informing the first node (GGSN) and/or a third node (RNC) of the multicast logical link; (3) determining whether or not at said first node (GGSN) and/or third node (RNC) there is an existing multicast logical link entry for that multicast group; and (4) if necessary creating a multicast logical link entry at the first node (GGSN) and/or third node (RNC), thereby establishing a multicast logical link between the first node (GGSN) and the third node (RNC). The second node (SGSN) may also configure and store in memory the first multicast identifier for the Gn interface at this stage and forward it to the first node (GGSN) such that it can then identify incoming M-PDUs from the first node (GGSN). The third node may also configure and store a second multicast identifier for the Iu interface at this stage and - 17 - forward it to the second node (SGSN) such that it can then identify incoming M PDUs from the first node (SGSN).

Advantageously, if a user of a mobile node wishes to leave a multicast group, the mobile node sends a leave request message over said individual logical link so as to cause said first, second and/or third node to remove the mobile node from their databases for that multicast group.

In one embodiment said leave request message is sent firstly to the mobile lo node's serving node (SGSN).

Preferably the method further comprises the step of tearing down the or each multicast logical link between the CN and RAN upon receipt of said leave request message if said mobile node is the last subscriber in the group.

Advantageously, the method further comprises the step upon receipt of a deactivation message for a mobile node's individual logical link, of ascertaining whether or not that mobile node is a subscriber of any multicast groups, and if so, removing that mobile node from the or each multicast logical link of which it is a subscriber.

Preferably, said deactivation message is firstly sent to the mobile node's serving node, the method further comprising the steps of sending a message to the first node (GGSN) to cause removal of a record of the mobile node's individual logical link, and the first node (GGSN) performing the steps set out above to remove the mobile node from the or each multicast logical link of which it is a subscriber.

Advantageously, said deactivation message is firstly sent to the mobile node's serving node, the method further comprising the steps of sending a message to the third node (RNC) to cause removal of a record of the mobile node's individual logical link, and the third node (RNC) performing the steps set out above to remove the mobile node from the or each multicast logical link of which it is a subscriber.

Preferably, said packet radio network is a Universal Mobile Telecommunications System (UMTS), said first node is a gateway GPRS support - 18 node (GGSN), said second node is a serving GPRS support node (SGSN), said third node is a third node (RNC), and said fourth node is a base station (Node B).

According to another aspect of the present invention there is provided a network node for use in a packet radio network, which network node comprises means for storing and executing computer executable instructions for performing a method or part of a method as claimed in any preceding claim. The network node may be a router that is a GGSN, SGSN or RNC, or any hierarchical equivalents.

lo According to another aspect of the present invention there is provided a network node for use in a packet radio network, which network node comprises means for storing and executing computer executable instructions for performing either: (1) any of the first node method steps as set out above; (2) any of the second node method steps as set out above; or (3) any of the third node method steps as set out above.

A computer program comprising computer executable instructions for causing a computer network node to perform either: ( 1) any of the first node method steps as set out above; (2) any of the second node method steps as set out above; (3) any of the third node method steps as set out above; or (4) any combination of (1) to (3).

It will be apparent that both the routing aspects of the invention as set out above and the group management aspects of the invention as set out above can be combined to provide an overall method. - 19

BR1EF DESCRIPTION OF THE DRAWINGS

For a better understanding of how the invention may be put into practice, a preferred embodiment of the invention applied to a UMTS network will be described, s by way of example only, with reference to the accompanying drawings, in which: Fig. I is a schematic representation of IMT-2000 UMTS architecture and its connection to external packet data networks (PDNs); Fig. 2 is a schematic representation of the protocol stacks in the user plane of the UMTS network of Fig. 1; 0 Fig. 3 is a block diagram of a gateway GPRS support node (GGSN) or serving GPRS support node (SONS) of the UMTS network of Fig. I in accordance with the present invention; Fig. 4 is a block diagram of a radio network controller (RNC) of the UMTS network of Fig. 1; Fig. 5 is a flowchart of the steps of a set of computer executable instructions stored and performed by the GGSN of Fig. 1; Fig. 6 is a flowchart of the steps of a set of computer executable instructions stored and performed by the SGSN of Fig. 1; Fig. 7 is a flowchart of the steps of a set of computer executable instructions stored and performed by the RNC of Fig. 1; Fig. 8 is a comparison of the multicast routing method of the present invention against standard UMTS routing based on tunnels; Fig. 9a is a schematic representation of encapsulation of an IGMP message within an 1P datagram; Fig. 9b is a schematic representation of the format of the fields in an IGMP message; Fig. 10 is a schematic representation of the signalling procedure for a multicast group join procedure in accordance with the present invention in the UMTS network of Fig. 1; Fig. 11 is a schematic representation of the signalling procedure for a multicast group leave procedure in accordance with the present invention in the UMTS network of Fig. 1; and Fig. 12 is a schematic representation of the signalling procedure for an implicit multicast group leave procedure in accordance with the present invention on the UMTS network of Fig. 1. - 20

The specification is set out in two sections: section 1 describes a multicast routing protocol and section 2 describes a multicast group management protocol, both for UM'I'S networks.

(1) Multicast Routing In UMTS Referring to Fig. I a UMTS network generally identified by reference numeral 1 comprises of several network nodes defined at the logical level and a 0 corresponding number of interfaces between the nodes. The IJMTS network 1 is divided into (a) the Core Network (CN) 2 consisting of the gateway GPRS support node (GGSN) 3 and the serving GPRS support node (SGSN) 4, and (b) the UMTS Terrestrial Radio Access Network (UTRAN) 5 consisting of the radio network controller (RNC) 6 and Node B 7. The GSNs (i.e. the GGSN and SGSN) constitute the backbone of the UMTS network 1. A brief description of the functionality of the network nodes shown in Fig. 1 relevant to the invention is given as follows: (1) Gateway GPRS Support Node (GGSN) 3: the GGSN 3 is used as an interface to external Packet Data Networks (PDNs) 8. The PDN 8 may be the Internet or a wide area network (WAN) for example. The GGSN 3 maintains routing information required to tunnel user data packets to the SGSN 4 serving a particular subscriber.

Other functions include network and subscriber screening and address mapping.

(2) Serving GPRS Support Node (SGSN) 4: the SGSN 4 delivers packets to subscribers within its service area. The SGSN 4 detects new mobile stations within a given service area, processes registrations of new mobile subscribers and keeps record of their location inside a given service area.

(3) Radio Network Controller (RNC) 6: the RNC 6 is the network element responsible for the control of the radio resources within the UMTS Terrestrial Radio Access Network (UTRAN) 5. The RNC 6 is responsible for load and congestion control of its own cells.

(4) Node B 7: the main function of the Node B 7 is to perform the air interface processing (channel coding and interleaving, rate adaptation, spreading, etc.). It also performs some Radio Resource Management. It logically corresponds to the GSM Base Station.

In UMTS, every Node B is connected to an RNC through the tub interface 9. - 21

Every RNC is connected to an SGSN through the lu interface 10. Finally, every SGSN is connected to a GGSN through the On interface 11. Mobile stations or handsets combined with the User Subscriber Identity Module (USIM) are referred to by the term User Equipment (UK) 12. "Mobile Station (MS)", a term used in the context of GSM and GPRS networks' is equivalent to the UE 12.

Further details of UMTS networks can be found in Third Generation Partnership Project, Technical Specification 23.060 v5.2.0' General Packet Radio Service (GPRS); Service Description; Stage 2' Release 5, June 2002 hereinafter 1 0 "3GPPTS").

In describing point-to-point or unicast packet routing for UMTS, two mechanisms are of central importance: the Packet Data Protocol (PDP) and the GPRS Tunnelling Protocol (GTP). PDP is the generic name for packet data transfer during an active session (see 1-1. Kaaranen e' al. "UMTS Networks" John Wiley and Sons' 2001). Before the UE 12 can exchange data with a host on the external PDN 8' the UE 12 must first establish a virtual connection with the UMTS network 1. This is similar to a dial-up connection established through the Public Switched Telephone Network (PSTN) in order to access a particular Internet Service Provider (ISP). In UMTS, virtual connections created and maintained within the network are referred to as "PDP contexts". The PDP context provides information to support packet delivery between the UE 12 and the UMTS network 1 and contains all parameters describing the packet data connection by means of end-point addresses and QoS. The PDP contexts are maintained in the UE 12, SGSN 4 and GGSN 3. A single UE may have several PDP contexts associated with it. The information contained within the PDP contexts is dynamic and changes as a result of user mobility.

The GGSN 3, SGSN 4 and the UE 12 maintain PDP contexts that list different items of information relevant to routing user data packets through the UMTS network 1. I he following is a partial list of this information: (a) PDP context identifier (used for indexing the list of stored PDP contexts); (b) PDP type (either X.25, PPP or IP); (c) POP address (e.g. an IPv4 address); 35(d) Access Point Name (APN), which is a logical name for an external - 22 network and/or service that the subscriber wishes to connect to; and (e) QoS information, such as the subscribed, requested and negotiated QoS profiles.

The GGSN 3 maintains activated PDP contexts consisting of routing information that allows the GGSN 3 to forward downlink user data packets to the serving SGSN 4. The SGSN 4 maintains activated PDP contexts consisting of routing information that enables the SGSN to forward user data packets either to the GGSN 3 in the uplink direction or to the serving RNC 6 in the downlink direction.

Instead of storing PDP contexts, the RNC 6 stores "Radio Access Bearer (RAB) contexts", which are roughly equivalently to the PDP contexts in that the RAB contexts allow the RNC 6 to receive user data packets from the SGSN 4 in the downlink direction and to forward packets to the serving SGSN 4 in the uplink I s direction.

GTP is a protocol that controls communication across the Gn 11, Gp and lu interfaces. GTP essentially tunnels multi-protocol (e.g. IP, UDP) packets through the UMTS backbone. GTP consists of two sub-protocols: GTP-(I is used for control signalling between the GGSN 3 and SGSN 4, whereas GTP-U is deployed in the user-plane from the GGSN 3 across the Iu interface to the serving RNC 6 in the UTRAN 5. On all interfaces G'l'P-U operates on top of the UDP/IP protocol family (see Fig. 2). GTP-U allows multi-protocol user data to be tunnelled across the respective interfaces. UMTS network elements and protocols transferring user data packets between UTRAN 5 and the GGSN 3 need not be aware of different addressing mechanisms at the IP (network) layer in order to be able to associate user data packets to specific PDP contexts. In encapsulating user data packets, GTP-U adds a GTP protocol header containing tunnelling information into every user data packet. The tunnelling information includes a 32-bit Tunnel Endpoint Identifier (TEID). The TEID is used to identify a PDP context (or in the Iu case a RAB context) inside a tunnel endpoint. The TEID is a unique identifier within one IP address of an RNC 6, SGSN 4 or GGSN 3 network node and has meaning only within the GTP protocol. The Network-layer Service Access Point (NSAPI) and International Mobile Subscriber Identity (IMSI) are used for network-layer routing.

In communication with the RNC 6 across the lu and Uu interfaces, the RAB ID is - 23 used to identify the radio access bearer and that information element is set to be identical to the NSAPI value. For the user plane, i. e. for G'I'P-U, each PDP context has a one-to-one relationship between the TEID on one hand, and NSAPI and IMSI on the other hand; or in the lu reference point case, between TEID and RAB ID and IMSI. However, the algorithm for computing the value of the TEID is implementation dependent (see 3GPP'l'S).

GTP-U tunnelling terminates at the RNC 6 within the UTRAN 5. Since GTP-C is only deployed over the Gn interface, the Radio Access Network lo Application Part (RANAP) protocol is used for establishing GTP-U tunnels between the SGSN 4 and the RNC 6.

In the context of UMTS routing, packets are usually referred to as Pl)P Packet Data Units (PDUs). Furthermore, PDP PDUs are routed as Network PDUs (N-PDUs) between the UE and the GGSN.

A brief overview of the GTP-based tunnelling procedure for mobileterminated packet transfers between the GGSN 3 and RNC 6 is given below: (1) Having received a PDP PDU, the GGSN 3 attempts to correlate the received PDU with any of the entries within its list of PDP contexts. When multiple PDP contexts exist for the same PDP address of a UE 12, the GGSN 3 routes downlink PDUs to the different GTP tunnels based on the Traffic Flow Template (TFT) assigned to PDP contexts (see 3GPPTS).

(2) Having successfully identified the correct PDP context, the GGSN 3 then encapsulates the N-PDU with a GTP header (using the TEID given in the PDP context) and forwards the N-PL)U to the SGSN 4 using the IP address of the SGSN 4 as specified by the PDP context.

(3) Once the SGSN 4 receives a N-PDU from the GGSN 3, the SGSN 4 is able to resolve the exact PDP context by correlating the TEID given in the GTP header with the TEID stored within its list of PDP contexts.

(4) Having identified the appropriate PDP context for the N-PDU (and 3s assuming that the addressed subscriber is in the Packet Mobility Management - 24 (PMM)-CONNECTED state), the SGSN 4 encapsulates and forwards the N-PDU to the appropriate serving RNC 6.

The UE 12 activates a PDP context by sending an Activate PDP Context Request message to the SGSN 4. The SGSN 4 validates the Activate PDP Context Request using the information provided by the UE and the PDP context subscription records. the SGSN 4 then sends a Create PDP Context Request message to the serving affected GGSN 3. The GGSN 3 creates a new entry in its PDP context table.

The new entry allows the GGSN 3 to route PDP Packet Data Units (PDUs) between 0 the SGSN 4 and the packet data network. The GGSN 3 then returns a Create PDP Context Response message to the SGSN 4. In Iu mode, Radio Access Bearer (RAB) setup is done by the RAB Assignment procedure. For each PDP Address a different quality of service (QoS) profile may be requested.

A PDP context establishes a mapping between a single subscriber and a generic PDP address (e.g. an IP address). A PDP context does not contain any references to external networks (e.g. addresses of web or email servers located outside of the UMTS network) or address identifiers for specific services that may be accessed by the subscriber while using a given PDP address. This is suitable for unicast connections since the majority of such connections require the subscriber to trigger the start of a session (e.g. web browsing or email). Multicast applications such as IP multicast on the other hand require an explicit mapping between the address identifier(s) of the subscriber(s) and an identifier of the multicast group that the subscriber(s) would like to join.

In considering one-to-many communications where a source wishes to distribute identical messages to m different subscribers within the UMTS network 1, the drawback of the UM I S routing procedures based on unicast tunnelling across the Gn and Iu interfaces becomes apparent. Since each tunnel is established for a single subscriber and an associated network access point identifier (i.e. the NSAPI), every PDU addressed to the multicast group will be transmitted n times between the GGSN 3 and SGSN 4 where n is the number of multicast subscribers that are located in the service area of the SGSN 4. The same applies over the lu interface: every multicast PDU will be forwarded p times between an SGSN 4 and an RNC 6 where p represents the number of multicast subscribers within the service area of the RNC 6. - 25

When considering all SGSNs and RNCs in the network the M-PDU will be sent m times in total. This clearly is wasteful of network bandwidth.

In order to support multicast connections in UMTS networks, a "multicast PDP (M-PDP) context" is introduced that establishes a mapping between the address of a multicast group and a sub-set of members of that group that are currently being served by a particular network node. M-PDP contexts are stored at the GGSN 3 and SGSN 4 to maintain routing parameters for distributing multicast messages within the network, as well as quality of service (QoS) characteristics that apply to members of 0 the multicast group. M-PDP contexts store the identities of multicast subscribers within the service area of a given network node. An M-PDP context at a GGSN 3

network node comprises following fields:

- M-PDP context identifier - M-PDP type used in external networks (e.g. IP multicast) - M-PDP address used in external networks (e.g. 238.255.254.1) - Multicast TE1D (M-TEID) for the Gn interface - QoS profiles - One or more multicast subscriber records. Each multicast subscriber record encapsulates a reference to an activated PDP context.

An M-PDP context at the SGSN network node 4 comprises following fields: M-PDP context identifier - M-PDP type used in external networks (e.g. IP multicast) - M-PDP address used in external networks (e.g. 238.255.254.1) - M-TEID for the Gn interface - M-TEID for the Iu interface - QoS profiles - One or more multicast subscriber records. Each multicast subscriber record encapsulates a reference to a mobility management (MM) and activated PDP context.

The RNC network node 6 does not maintain PDP contexts. Instead it stores RNC Radio Access Bearer (RAB) contexts that allow the node to resolve the subscriber that is associated with a GTP-encapsulated N-PDU received from an SGSN 4. In analogy to M-PDP contexts, multicast group membership at the RNC is managed by means of"multicast RAB (M-KAB)" contexts that store references to - 26 the actual RNC RAB contexts maintained at the RNC node 6. A RNC M-RAB context stores following entries: - M-PDP context identifier - M-PDP type used in external networks (e.g. IF multicast) M-PDP address used by external networks (e.g. 238.255.254.1) - M-TEID for the lu interface - QoS profiles - One more multicast subscriber records. Each multicast subscriber record encapsulates a reference to an RNC and activated RNC RAB context.

An M-RAB groups together several RABs and as such is not a true RAB in itself. Both M-PDP and M-RAB contexts store all pertinent details(multicast protocol, multicast address and QoS parameters) that are valid for a single multicast group. Several M-PDP and M-RAB contexts with the same M-PDP type, address and is QoS profiles but different multicast subscription records are maintained at different GSN and RNC network nodes throughout the UM'I'S network. Therefore each M-PDP or M-RAB context stored at a particular GSN or RNC node contains a sub set of the multicast subscribers that are present within the network. A single M-PDP or M-RAB context maintains multicast records for all multicast subscribers located within the service area of the network node. Each GSN or RNC network node may store one or more M-PDP or M-RAB contexts for each multicast group serviced within the location area of the network node. All M-PDP contexts with the same M-PDP address share the same M- TEID for either the Cn or lu interfaces. Hence, all multicast messages within a group are tunnelled with the same M-TEID using GTP over either the Gn or lu interface. This is in contrast to conventional TEIDs that tunnel user data for individual users only. A single multicast message is sent exactly once between any two network nodes over the Gn and lu interfaces using the M-TEID for the group independent of how many multicast subscribers are within the service area of the receiving network node. A single network node such as the GGSN 3 must replicate the multicast message in order to forward it over the Gn interface to all SGSN network nodes that are servicing multicast subscribers for the group. The same applies to multicast message forwarding over the lu interface between SGSN 4 and RNC 6 network nodes.

Every M-PDP or M-RAB context maintains a multicast subscriber record for 27 each multicast subscriber (i.e. user subscribing to the multicast group) within the service area of the particular network node. A multicast subscriber record encapsulates a reference to the relevant routing, mobility management or radio access bearer details for that particular multicast subscriber. The entries within a multicast subscriber record allow the GGSN 3 to extract the PDP context, the SGSN 4 to extract the MM and PDP contexts and the RNC 6 to extract the RNC and RAB contexts of a particular multicast subscriber. Maintaining references to the routing, mobility, radio network control and radio access bearer records and not the actual records themselves has the advantage that the location update procedures performed lo by the network remain largely unchanged. In order to accommodate location update and handover procedures, the PDP contexts that are referenced by multicast subscriber records must contain a reference to the M-PDP context they are associated with. The same applies to the M-RAB contexts in that the RAB contexts must contain a reference to any associated M-RAB contexts. The PDP and RAB contexts that are - 15 used for multicast message forwarding therefore maintain an additional field storing the identifier of the M-PDP or M-RAB context they are associated with.

A multicast subscriber record within an M-PDP context consists of following

fields:

- International Mobile Subscriber Identity (IMSI) - Transaction Identifier (TI) of PDP context to be referenced for extracting multicast subscriber routing details.

- NSAPI of PDP context to be referenced for extracting multicast subscriber routing details.

- TEID of PDP context to be referenced for extracting multicast subscriber routing details.

A multicast subscriber record within an RNC M-RAB context stores

following fields:

- IMSI

- RAB ID

Based on the fields encapsulated within the multicast subscriber records within an M-PDP or RNC M-RAB context, the GGSN 3, SG8N 4 and RNC 6 are able to perform a look-up of the PDP, MM, RNC and RAB contexts that hold the - 28 routing, mobility management, radio network control and radio access bearer information for multicast subscribers.

The multicast routing procedure based on M-PDP and RNC M-RAB contexts only considers the downlink direction between the GGSN 3 and the RNC 6. The connection between the RNC 6 and the Node B 7 depends on the air interface and is therefore largely dependent on radio resource management. All uplink traffic is routed based on conventional UMTS routing procedures and is therefore transparent to the multicast routing scheme. Due to this only the GGSN 3 and SGSN 4 must lo forward downstream multicast messages, whereas the RNC 6 must only resolve the multicast G'l'P tunnels in order to extract the RNC and RNC RAB contexts of the subscribers being served by the RNC node. The RNC 6 then replicates the data in the multicast packet for transmission over the air interface to each multicast subscriber.

M-PDP contexts have respective M-TETDs for the Gn and Iu interfaces (first and second M-TEIDs). The GTP protocol tunnels all multicast messages using the M-TEIDs given by the M-PDP context for that multicast group. The multicast tunnels are established using the signalling protocol GTP-C between the GGSN 3 and SGSN 4 and the signalling protocol RANAP between the SGSN 4 and RNC 6. The algorithm for computing the M-TEID is implementation-specific. Due to an anticipated inter-operation of the proposed UMTS multicast scheme with IPv4 multicast, the M-TEID may be readily set equal to the 32-bit class D multicast address of the IPv4 multicast group. The M-TEID of the M-PDP context is always used for multicast message forwarding and overrides the TEID stored in the PDP contexts referenced by individual multicast subscriber records.

Fig. 3 shows the GGSN 3 in more detail that comprises a case 21 having network interface ports 22 and 23 to which respective cables 24 and 25 provide a physical link to IP network 8 and the UMTS network 1. Two network interface cards 26 and 27 are connected to their respective network interface ports 22 and 23. A hardware packet switch 28 connects the network interface cards 26, 27 and a central processing unit (CPU) 29 can communicate with a routing table 30 and router management tables 31.

Each network interface card 26, 27 comprises a link layer protocol controller - 29 32 that has access to an interface management table 33 and a hardware address table 34 (e.g. Address Resolution Protocol cache). In communication with the link protocol controller 32 is a network protocol-forwarding engine 35 having access to a forwarding table 36 (route cache), and an interface queue manager 37. Both the s network protocol forwarding engine 35 and interface queue manager 37 have an interf ce to and from the packet switch 28 respectively.

In use, frames are received by the link layer protocol controller 32 that handles the link layer protocol (e.g. IIDLC, Ethernet) used over the physical link.

lo Frame integrity is checked and valid frames are converted into packets by removing the link layer header and, if necessary, the packets are queued in a queue 38. Storage capacity is often in the form of a ring of memory buffers. One packet at a time is removed from the queue 38 by the network protocol-forwarding engine 35 and the forwarding table 36 determines whether or not the packet requires detailed examination by the CPU 29. Via the CPU 29 the SGSN to which the packet should be sent obtained from the PDP context associated with the IP address of the UE that the packet is destined. Once the destination IP address of the SGSN is found the CPU searches the ARP cache for a Media Access Control (MAC) address for the destination. A GTP header is added to the datagram that contains the TEID of the POP context. The datagram (including GTP header) is then encapsulated in an IP packet header with a destination address of the SGSN. The CPU 29 now knows where to send the packet and the new link layer header to use. The link layer address is added and the packet is linked into the list of frames to be sent on from the appropriate network interface card. The packet is then forwarded to the packet switch 28 and onto the network interface card where the packet joins a queue 39 to be processed by the interface queue manager 37. From here the packet joins one of a number of link output queues 40 until the link layer protocol controller 32 can process it. The link layer protocol controller 32 encapsulates the packet in a link layer header that includes the Media Access Control (MAC) address of the SGSN to which the packet is to be sent. The MAC address is obtained from the hardware address table 34. The packet is then placed on the physical channel by the link layer protocol controller 32.

Various types of GPRS support node are available and the present invention is not limited to that described above. Further examples are available from Cisco À 30 Systems, Inc. (www.cisco.com), Siemens AG (www. siemens.com) and Alcatel (www.alcatel.com) for example.

In addition the CPU 29 of the GGSN 3 has access to a memory 40. The memory 40 stores the computer executable instructions that must be performed and the context database that must be created and maintained by the GGSN 3 in performing the multicast routing and administration described below. In particular, the memory 40 stores the PDP context and M-PDP contexts of subscribers.

lo The SGSN 4 is similar in construction and operation to the GGSN 3.

I-Iowever, in addition to the PDP and M-PDP contexts, the memory in the SGSN 4 stores a context database that contains all mobility management (MM) contexts for the subscribers within its service area.

Fig. 4 shows part of the RNC 6 in more detail that comprises a receiver 41, a control unit 42 (e.g. CPU), a transmitter 43 and a memory 44. In use the receiver 41 receives N-PDUs from the SGSN 4 and Node B 7. As will be described in greater detail below the control unit 42 of the RNC 6 is able to reference various M-RAB contexts held in the memory 44 of the RNC 6.

In the following section a detailed description of multicast message forwarding based on M-PDP and RNC M-RAB contexts at the GGSN 3, SGSN 4 and RNC 6 is given.

The GGSN 3 interfaces with external PDNs, such as the Internet, and is the entry point to the UMTS network I for all traffic originating from external sources.

Multicast traffic may originate from outside of the IJMTS network 1 as well as from within the network. It is assumed that multicast traffic originating from within the network interfaces with the GGSN in the same fashion as multicast traffic originating from external PDNs.

Referring to Fig. 5 the first step Sl in performing multicast routing based on M-PDP contexts is for the GGSN 3 to identify the M-PDP context that corresponds to a multicast message that it has received. This is done by evaluating each PDI' and M-PDP context stored at the GGSN until the matching record is found. Depending on 31 whether the multicast protocol being used allows the network to distinguish unicast from multicast messages (e.g. based on the address), the matching process may be optimised by only searching for a matching M-PDP context and bypassing the list of stored PDP contexts if the received message is a multicast message. This optimisation may be applied in the case of IP multicast since unicast messages are easily distinguished from multicast messages by simple inspection of the IP address.

In this case the GGSN will search for the M-PDP context that contains the multicast address of the packet it has received. If there is no match at step S2, the GGSN 3 silently discards the received multicast packet at step S3.

If there is match a step S2, the GGSN 3 begins iterating through the multicast subscriber records of the M-PDP context at step S4 and extracts the NSAPI, TEID and IMSl fields from each record. At step S5 these fields are used in order to perform a look-up of the appropriate PDP context in use by the multicast subscriber. It is possible to just use the NSAP1 and TEID to do this. However, by also using the IMSI greater reliability of searching is obtained. Should the NSAPI, TEID and IMSI fields not reference a valid PDP context, the corresponding multicast subscriber record is removed from the M-PDP context. The PDP context look-up is performed in order to determine the addresses of the SGSNs serving each multicast subscriber within the M-PDP context at step S6. The addresses of the serving SGSNs for each multicast subscriber are stored in a list of SGSN addresses at step S7. The list of SGSN addresses may contain duplicate entries since several multicast subscribers may be located within the same SGSN service area. The GGSN then replicates and forwards the incoming multicast message such that it is sent once to each SGSN address in the list at step S8. Multicast message forwarding is performed by tunnelling the multicast message using the M-TEID (Gn interface) of the M-PDP context and subsequently encapsulating the tunnelled message with UDP/IP using the address of each SGSN within the list.

The steps required for performing multicast routing based on the M-PDP contexts at the GGSN 3 are summarized as follows: ( I) The GGSN correlates an incoming multicast message with the matching M-PDP context by evaluating each PDP and M-PDP context it has stored until a match is found. - 32

(2) Using the NSAPI and IMSI encapsulated within each multicast subscriber record in the M-PDP context, the GGSN 3 performs a look-up of the PDP context associated with the multicast subscriber. Should the NSAPI and IMSI not reference a valid PDP context, the multicast subscriber is removed from the M-PDP context. Having identified the correct PDP context for the multicast subscriber, the GGSN 3 adds the address of the SGSN 4 serving that subscriber given in the PDP context to a list of SGSN addresses.

0 (3) For each unique SGSN address within the list, the GGSN 3 duplicates the received multicast message and forwards it to the SGSN using the MTEID (Gn interface) of the M-PDP context and the address of the SGSN taken from the list.

Thus the multicast message is forwarded only once over each link between the GGSN and any number of SGSNs serving multicast subscribers in the group.

Referring to Fig. 6 once the SGSN 4 receives an incoming message, it searches at step S I for a matching M-PDP context based on the M-TEID (i. e. the M TEID for the On interface) of the GTP-encapsulated message. Slaving found an M-PDP context that matches the encapsulated message, the SGSN 4 extracts the Tl and IMSI fields from the first multicast subscriber record in the M-PDP context at step S2. At step S3 the SGSN 4 performs a look-up of the MM context referenced by the IMSI field of that multicast subscriber record. At step S4 the SGSN checks whether the MM state is PMM-CONNECTED or otherwise for that subscriber. If the MM state is not PMM-CONNECTED, the SGSN 4 performs a PS Signalling Connection Establish procedure in order to bring the MM context to the PMM-CONNECTED state. Once the MM context is in the PMM-CONNECTED state, the SGSN 4 looks up the PDP context associated with that subscriber at step S5 using the IMSI and Tl values. At step S6 the SGSN extracts the RNC address given in the PDP context and adds it to a list of RNC addresses of multicast subscribers within the M-PDP context at step S7. The routine returns to step S2 and performs the above steps for the next subscriber in the M-PDP context. T his is repeated until all of the subscribers associated with the M-PDP context have been processed. The result is a list of RNC addresses to which the multicast message must be forwarded. At step 3s S8 the SGSN 4 forwards a copy of the multicast message once to each unique entry - 33 within the list of RNC addresses, using a GTP header containing the M-TEID of the In interface. The packet is then encapsulated using UCP/IP and forwarded to each RNCs serving subscribers.

The steps required for performing multicast routing at the SGSN are summarized as follows: (1) As with conventional N-PDUs received at an SGSN node, the SGSN searches for a PDP or M-PDP context that matches the N-PDU based on the TEID or 0 M-TE1D of the GTP-encapsulated message. Assuming that the received N- PDU is a multicast message (i.e. M-PDlJ), the SGSN finds a matching M-PL) P context.

(2) The SGSN iterates through the multicast subscriber records in the MPDP context and performs a look-up of the MM and PDP context records associated with the multicast subscriber record based on the IMSI and TI fields.

Should the multicast subscriber record not reference a valid MM or PDP context, the multicast subscriber is removed from the M-PDP context.

(3) For the MM context associated with a multicast subscriber record, the SGSN checks whether the MM state is PMM-CONNECTED. If the MM state is not PMM-CONNECTED, the SGSN performs the PS Signalling Connection Establish procedure.

(4) Once the multicast subscriber is in the PMM-CONNECTED state, the SGSN adds the RNC address of the PDP context referenced by the multicast subscriber record to a list of RNC addresses.

(5) The SGSN duplicates and forwards a copy of the multicast message to each unique element within the list of RNC addresses using the lu interface M-TEID of the M-PDP context.

Thus the multicast message is forwarded only once over each link between the SGSN and any number of RNCs serving multicast subscribers in the group.

Referring to Fig. 7 once an RNC 6 receives a GTP-encapsulated N-PDU, the 34 RNC checks its list of RAB and M-RAB contexts for a matching record at step Sl based on the TEID or M-TEID of the GTP header. Assuming that the received N-PDU is indeed a multicast message, the RNC is able to identify the appropriate M-RAB context associated with the M-PDU. At step S2, the RNC is then able to identify the records of the multicast subscribers from the M-RAB and extracts the RAB ID and IMSI from the first subscriber record. At step S3 the RNC then extracts the RAB context for that record. The process is then repeated so as to identify all of the RAB contexts associated with the subscribers in the M-RAB. The exact mechanism of forwarding multicast messages at step S4 to the Node Bs serving the lo multicast subscribers stored in the RNC M-RAB context is by and large dependent on radio resource management. The RNC is the point in the network at which IP addressing ceases in the downlink direction. It is the decision of radio resource management how best to distribute the multicast message from the Node B. For example this might be done by a broadcast over the wireless link, or by duplication of the message and sending over dedicated or common channels.

Summarising, the steps the RNC 6 needs to perform in order to identify multicast messages and distribute these appropriately are the following: (1) As with conventional N-PDUs received at an RNC node, the RNC searches for a RAB or M-RAB context that matches the N-PDU based on the TEID or MTEID of the GTP-encapsulated message. Assuming that the received N-PDU is a multicast message, the RNC finds a matching M-RAB context.

(2) Based on the multicast subscriber records stored as part of the M-RAB, the RNC is able to resolve which subscribers belong to the multicast group.

The RNC then forwards the multicast messages to the serving Node Bs either on dedicated or common channels based on suitable radio resource management strategies.

Location update procedures are required so that the network can track the location of subscribers within the network. Due to the fact that M-PDP and M-RAB contexts only maintain references to the actual records of multicast subscribers, all MM, PDP, RNC and RAB context records are updated in the usual fashion according to the location management procedures described in 3GGPTS. This helps to save - 35 network resources as M-PDP contexts and M-RAB contexts do no need to be updated with mobility management details.

In performing an inter-SGSN update the MM and PDP context information of a subscriber must be transferred between the old and new SGSN (see 3GPPTS pg 64). The procedure of transferring the MM and PDP context records in the context of multicast traffic distribution based on M-PDP contexts requires that the old SGSN check the PDP context to be transferred for an associated M-PDP context. This is easily done by checking whether the MPDP context identifier field in the PDP lo context is void or not. If the PDP context is associated with an M-PDP context, the SGSN must additionally transfer the M-PDP context in addition to the MM and PDP contexts. The new SGSN then either establishes a new M-PDP context or updates an existing one with the details of the subscriber.

A similar procedure is carried out in performing the relocation of the serving RNC (SRNC). In this case, the source RNC checks whether the RAB information elements that are being requested by the target RNC for reallocation contain an association with an M-RAB context. If this is the case, the source RNC transfers the M-RAB details to the target RNC alongside the RAB information elements of the multicast subscriber. At the target RNC, either a new M-RAB is created or an existing one updated with the details of the subscriber.

Referring to Fig. 9 a performance graph of the multicast routing method described above generally identified by reference numeral 45. The performance graph 45 shows the multicast method 46 in comparison to the conventional m-times unicast method 47. The x-axis shows a logarithmic scale of the number of multicast users within a Routing Area (RA) of the UMTS network 1 i.e. the area covered by a number of cells. the y-axis shows the number of multicast packets sent to the RA between the GGSN 3 and an RNC 6 via one SGSN 4. In the existing UMTS architecture a PDP context exists for each mobile node connected to the network.

Accordingly when a multicast packet arrives at the GGSN, it must be copied and tunnelled via each PDP context for the subscribers in the group. However, when employing the multicast method described above only one dedicated multicast tunnel or logical link need be established for the subscribers. Accordingly the multicast packet need only be sent once over the UMTS network as shown by line 46. - 36

lt will be appreciated that where subscribers to the same multicast group are served by different SGSNs and RNCs, it will be necessary to establish more than one dedicated multicast logical link for that group on the network. Nevertheless, where s there are two or more subscribers per SGSN or per RNC, network resources can be saved by use of the dedicated multicast logical link. In particular, the maximum number of multicast logical links needed between the GGSN and SGSNs is equal to the number of SGSNs serving subscribers of the group. Similarly, the maximum number of multicast logical links needed between one SGSN and RNCs served lo thereby, is equal to the number of RNCs serving subscribers of the group. More might be established, however, if different qualities of service need to be provided to subscribers of the same multicast group for example.

Accordingly, in some scenarios the line 46 in Fig. 9 may not necessarily be flat, as the multicast packet will need to be copied at the GGSN and SGSN according to the number of multicast logical links (M-PDP contexts) required to serve all subscribers of the group. Nevertheless in most cases the UMTS multicast method is likely to result in far fewer packets by sent across the network than the unicast method.

(2) UMTS Multicast Group Management Group management in UMTS requires both support for group establishment and administration within the network as well as appropriate inter-operation with as external networks, since multicast traffic in many cases will originate from external networks. Therefore group management for UMTS requires the network to keep track of group members within the network and, depending on which groups are present, inform external network of what multicast traffic the network wishes to receive. This approach is equivalent to the model adopted in IP multicast, the most widely deployed multicast protocol in use today.

Figure 9a shows an IPv4 datagram 50 that comprises an IGMP message 51 within a header 52. IPv6 datagrams are constructed in similar fashion. Bearing in mind that IGMP messages are encapsulated in IP packets as shown and therefore 3s cannot be processed by intermediate UMTS network nodes, IGMP or Ml,D messages - 37 must traverse from the UE 12 to the GGSN 3 before any action in response to the join/leave request can be taken. This is clearly inefficient and places additional load on the GGSN that already performs many important tasks. Figure 9b illustrates the format of IGMP messages.

Subscribers within the UMTS network I may join and leave multicast groups using explicit signalling procedures. Should the connection to a multicast subscriber become invalid at any stage, the UM'1'S network 1 performs an implicit leave procedure for the multicast subscriber.

Subscribers use the M-PDP context join procedure to inform the UMTS network I that they wish to belong to a multicast group. Based on the MPDP context join procedure the UMTS network learns which groups have members within the network.

Subscribers that wish to join a multicast group must previously have activated a PDP or secondary PDP context using the standard procedures for PDP context activation. Additionally, subscribers that wish to join a multicast group must have an activated RNC RAB context prior to issuing an M-PDP context join request.

Requesting to join an M-PDP context is equivalent to joining a multicast group, although no protocol is needed at the IP layer (e.g. MLD or IGMP) to inform get GGSN to start forwarding packets from an external PDN. The M-PDP context join request requires that the multicast subscriber specify following details: - M-PDP type used in external networks (e.g. IP multicast) - M-PDP address used in external networks (e.g 238.255.254.1) Requested QoS profile - Transaction Identifier (TI) of PDP context to be used for multicast message forwarding.

When the UMTS network I receives an M-PDP context join request from the UE 12, it either adds a multicast subscriber record to any existing M-PDP or M-RAB context records at the SGSN 4, GGSN 3 and RNC 6 network nodes or creates new M-PDP or M-RAB context provided there are no existing multicast contexts with the same M-PDP address at the network nodes in question. In the case that new multicast - 38 contexts must be created, the subscriber wishing to join the group is added to the empty list of multicast subscriber records of the newly-created multicast M-PDP or MRAB context. If an M-PDP or M-RAB context had previously been established for a particular multicast group, the subscriber wishing to join the group is added to the non-empty list of multicast subscriber records. If a new M-PDP context was created at the GGSN 3, the GGSN establishes the required inter-operation with external networks so that the network can receive multicast traffic for the group, for example by sending unicast a join message to a central multicast router.

lo Referring to Fig. 11 the basic join mechanism of the proposed multicast group management scheme based on M-PDP contexts consists of the following steps: (1) The lJE 12 with an activated PDP context wishing to join a multicast group sends the Join M-PDP Context Request message to the SGSN4 at step S I The Join M-PDP Context Request message specifies the M-PDP type, M-PDP address and the requested QoS profile Furthermore, the M-PDP context join request encapsulates the Tl of the PDP context to be used for multicast message forwarding.

(2) The S(,SN 4 may (optionally) validate the M-PDP context join request based on the M-PDP type and M-PDP address provided by the UK. The SGSN 4 performs a PDP context look-up using the TI specified in the M-PDP context join request in order to check whether a PDP context has been established for the subscriber. If the TI does not reference a valid PDP context, the SGSN 4 rejects the M-PDP context join request. However, if the TI does reference a valid PDP context but the SGSN 4 does not have an M-PDP context for the M-PDP context address specified in the Join M-PDP ContextRequest, the SGSN creates a new M-PDP context and adds the UE 12 as a multicast subscriber to the M-PDP context.

The SGSN also creates and stores a first M- I KID for the new M-PDP context for use on the Gn interface. The first M-TEID may be the IP multicast address in an IPv4 network. This information is stored in a context database in the memory of the SGSN. If there is an existing M-PDP context for a given M-PDP context address in the context database, the SGSN 4 adds a multicast subscriber record to the existing M-PDP context. The first M-TEID of the M-PDP context is inserted into the PDP context referenced by the TI. - 39

(3) At step S2 the SGSN sends a Join M-PDP Context Request message to the GGSN 3 that is specified in the PDP context referenced by the multicast subscriber record. The Join M-PDP Context Request includes the M-PDP types M TEID, address and requested QoS profile as well as the TEID/NSAPI of the PDP context to be used for multicast forwarding. The GGSN 3 either creates a new M-PDP context or adds the multicast subscriber record to an existing M-PDP context in a context database a stored in memory. The identifier (M-TEID) of the M-PDP context is inserted into the PDP context referenced by the TEID and NSAPI fields.

0 (4) If the GGSN 3 does not have an M-PDP context for the M-PDP context address specified in the Join M-PDP Context Request in memory, the GGSN creates a new M-PDP context and adds the UE 12 as a multicast subscriber to the M-PDP context. If there is an existing M-PDP context for a given MPDP context address, the GGSN adds a multicast subscriber record to the existing M-PDP context.

: 15 If the GGSN 3 created a new M-PDP context for the multicast subscriber, the GGSN activates multicast forwarding with external networks at step S3. In the case of IP multicast, the network may deploy any of the protocols in use today (DVMRP, MOSPF), the exact mechanism for joining the group is dependent on the protocol used for that purpose. At step S4 the GGSN 3 responds to the SGSN 4 with a Join M-PDP Context Response in order to confirm the activation of the M-PDP context.

(5) Once the SGSN 4 has received a confirmation that the GGSN has performed the required steps for adding a subscriber to a multicast group, the SGSN sends a M-RAB Assignment Request at step S5 to the serving RNC 6. The M-RAB Assignment Request contains the M-PDP address as well as the IMSI and RAB ID (which is equivalent to the NSAPI of the PDP context) of the RAB context belonging to the multicast subscriber. The RNC checks whether it has an existing M-RAB context with the same M-PDP address. If the RNC has an existing M-RAB context in a context database in memory, a new multicast subscriber record is added to the multicast context. Otherwise a new M- RAB context is created and the multicast subscriber is inserted into the multicast context. In this case the RNC also creates and stores a new second M-TEID for the lu interface for use by the SGSN. The second M-TEID may be the IP multicast address in an IPv4 network. The second M-TEID of the new M-RAB context is inserted into the RAB context to be referenced for multicast transmission. The M-RAB Assignment Request does not result in the - 40 establishment of radio access bearer between the RNC 6 and the UE 12 since the actual transport of multicast messages is done with existing RABs assigned to the multicast subscriber.

(6) At step S6 the RNC 6 confirms that the subscriber has been added to an M-RAB by sending an M-RAB Assignment Response to the SGSN 4. Whether or not the M-RAB is new multicast logical link, this response includes the second M TEID or new second M-TEID to the SGSN.

lo The M-PDP Context Update Request and Response messages are needed if the RNC has downgraded the requested QoS profile of the multicast subscriber, in which case the SGSN must inform the GGSN of the downgraded QoS profile assigned to the multicast tunnel.

(7) At step S7 the SGSN 4 sends the Join M-PDP Context Accept message as a confirmation to the UK.

The M-PDP context request and response messages differ from the conventional PDP context request and response messages only in the information elements conveyed by the request and response messages.

When a UE 12 wishes to leave at multicast group it performs an M-PDP context leave procedure described in greater detail below.

In order to leave a multicast group, the multicast subscriber UE 12 sends a Leave M-PDP Context Request to the SGSN 4, specifying the M-PDP context details and the TI of the PDP context associated with the M-PDP context. The SGSN 4 and GGSN 3 network nodes then remove the multicast subscriber record from the M-PDP context or the entire M-PDP context if the multicast subscriber is the last subscriber within the M-PDP context. If the entire M-PDP context was removed, the GGSN signals to external networks that the network does not wish to receive any further multicast traffic for the multicast group.

The M-PL)P context leave procedure is shown in greater detail in Fig. I I and consists of following steps: - 41 (1) At step S1 the UE 12 sends a Leave M-PDP Context Request to the SGSN 4, specifying the M-PDP context details (M-PDP context type, M-PDP context address) and the required multicast subscriber details (TI).

(2) In response to the message sent at step S1, the SGSN 4 removes the appropriate multicast subscriber record from the M-PDP context in the context database and removes the entire M-PDP context if the multicast subscriber was the last subscriber record within the M-PDP context. The SGSN 4 removes the M-PDP lo context identifier field in the PDP context that was associated with the M-PDP context.

(3) At step S2 The SGSN sends a Leave M-PDP Context Request to the GGSN 3, specifying the multicast subscriber record details of the subscriber wishing to leave the group (NSAPI and TEID). The I,eave M-PDP context Request also specifies the first M-TEID to enable the GGSN 3 to identify the M-PDP context.

(4) In response to the message sent at step S2, the GGSN 3 removes from its context database the multicast subscriber record in the M-PDP context for the subscriber wishing to leave the group or the entire M-PDP context if the multicast subscriber is the last subscription record within the MPDP context. The GGSN removes the M-PDP context identifier field in the PDP context that was associated with the M-PDP context. At step S3 the GGSN 3 then terminates multicast forwarding with external networks.

(5) At step S4 the GGSN 3 responds with a Leave M-PDP Context Response, confirming that the multicast subscriber has been removed from the group.

(6) In response to the message sent at step S4, the SGSN 4 sends the Leave M-RAB Assignment Request to the serving RNC at step S5 that specifies the second M-TEID so that the RNC can identify the M-RAB context. In response to this the RNC 6 removes the multicast subscriber from the M-RAB context. Alternatively the M-RAB context is deleted if the subscriber was the last entry in the multicast subscriber records and the M-RAB identifier is removed from the RAB context used by the subscriber. - 42

(7) At step S6 The RNC 6 confirms that the subscriber has been removed from an M-RAB by sending an M-RAB Assignment Response to the SGSN 4.

(8) The SGSN 4 confirms to the IJE that the M-PDP context deactivation is completed at step S7 by sending a Leave M-PDP Context Accept message.

In order to ensure that the multicast subscriber records within an M-PDP context always maintain references to valid MM and PDP contexts, the GGSN 3 and lo SGSN 4 may either perform an implicit multicast leave procedure or activate a new PDP context should a multicast subscriber have deactivated a PDP context that is associated with an M-PDP context. An implicit multicast leave procedure is shown in Fig. 12 and is performed as follows: ( I) At step S I the UE 12 initiates the PDP Context Deactivation procedure as specified in 3GPPTS by sending a Deactivate PDP Context Request message to the SGSN 4. The UE 12 specifies the Tl of the PDP context to be deactivated.

(2) In response, the SGSN 4 correlates the PDP context deactivation request message with its list of stored PDP contexts. Having identified the PDP context that the UE 12 would like to deactivate, the SGSN checks whether there is an associated M-PDP context by checking for an entry in the M-PDP context identifier field. Should the M-PDP context identifier field in the PDP context not be void, the SGSN removes the multicast subscription record of the UE 12 within the appropriate M-PDP context. The entire M-PDP context is deleted if the multicast subscriber was the last entry within the multicast subscriber record list.

(3) At step S2 the SGSN 4 sends the Delete PDP Context Request to the GGSN 3 according to the standard procedure (see 3GPPTS).

(4) In response to this message, the GGSN 3 checks whether the PDP context to be deleted is associated with an M-PDP context and if this is the case, removes the multicast subscription record of the UE in the M- PDP context. The GGSN deletes the entire M-PDP context if the subscriber was the last entry within - 43 the multicast subscriber list and deactivates multicast message forwarding from external networks at step S3.

(5) At step S4 the GGSN responds to the SGSN with a Delete PDP s Context Response.

(6) At step S5 the SGSN 4 sends a Deactivate PDP Context Accept to the UE 12.

(7) The SGSN 4 sends the RAB Assignment Request to the serving RNC 6 in order to perform radio access bearer release at step S6. The RNC 6 checks whether the RAB to be released is associated with an M-RAB context. If this is the case the RNC removes the appropriate record from the M- RAB multicast subscriber list. The RNC subsequently performs the radio access bearer release procedure.

The above procedure is equivalent to the standard PDP context deactivation procedure apart from the steps that require modification of the M-PDP and RNC M-RAB contexts. The implicit multicast leave procedure may be suitable in order to avoid delays in delivering multicast packets to all members within the group. On the other hand, the GGSN may perform the network-requested PDP context activation procedure (see 3GPPTS) in order to re-activate a PDP context that has become invalid. This in turn will result in delays in distributing multicast messages to subscribers.

Some advantages of the above multicast group management scheme are that multicast group join/leave latency is reduced as join/leave messages do not traverse the entire UMTS network I bet'ore being processed. As multicast group subscription is based on the mechanisms of PDP context activation and deactivation, all multicast join/leave messages are acknowledged by the network 1. Multicast group management based on the MPDP context join procedure facilitates integration with UMTS-specific mechanisms such as QoS and routing It will be apparent that although the invention, both routing and group management aspects, have been described with reference to a UMTS network, they are applicable to any packet radio network or any network in which the IP layer - 44 containing multicast information is not "visible" to the network such that multicast addresses and protocols cannot be used without high overheads on network resources. This includes packet radio networks that use tunnel-based mobility schemes to route IP datagrams in so-called "all IP" networks. One example is hierarchical mobile IP in IPv6 networks (see Chiussi e' al. "Mobility Management in Third-Generation AII-IP Networks", IEEE Communications Magazine, September 2002).

Furthermore, the invention may be applied between any combination of 0 network nodes e.g. between GGSN and SGSN only, or between SGSN and RNC only. However, it is believed that the greatest advantages will be achieved by applying the methods to the last (in a downlink sense) network layer addressable node before the wireless or air interface in the network.

The references in parentheses in the appended claims are to facilitate ease of understanding and in no way should be construed to limit the network type or type of network node to those mentioned. The claims extend to all hierarchical equivalent nodes in packet radio networks.

Although the embodiments of the invention described with reference to the drawings comprise computer apparatus and methods performed in computer apparatus, the invention also extends to computer programs, particularly computer programs on or in a carrier, adapted for putting the invention into practice. The program may be in the form of source code, object code, a code intermediate source and object code such as in partially compiled form, or in any other form suitable for use in the implementation of the methods according to the invention. The carrier may be any entity or device capable of carrying the program.

For example, the carrier may comprise a storage medium, such as a ROM, for example a CD ROM or a semiconductor ROM, or a magnetic recording medium, for example a floppy disc or hard disk. Further, the carrier may be a transmissible carrier such as an electrical or optical signal that may be conveyed via electrical or optical cable or by radio or other means.

When the program is embodied in a signal that may be conveyed directly by a - 45 cable or other device or means, the carrier may be constituted by such cable or other device or means.

Alternatively, the carrier may be an integrated circuit in which the program is embedded, the integrated circuit being adapted for performing, or for use in the performance of, the relevant methods. - 46

Claims

1. In a packet radio network comprising a radio access network (RAN) and a core network (CN) via which a plurality of mobile nodes may communicate over a wireless link with an external packet data network, a method of forwarding multicast packet data units (M-PDUs) for a multicast group to at least one subscriber mobile node subscribed to the multicast group, which method comprises the steps of: (1) receiving an M-PDU at a first node (GGSN) in said CN; (2) identifying at least one second node (SGSN) responsible for said at lo least one subscriber mobile node; and (3) where a second node (SGSN) serves multiple subscriber mobile nodes, forwarding said M-PDU from the first node (GGSN) to the or each second node (SGSN) via a number of multicast logical links that is less than the number of subscriber mobile nodes of the multicast group served by each second node (SGSN) respectively.

2. A method as claimed in claim 1, wherein said M-PDU is forwarded to the or each second node (SGSN) responsible for said at least one subscriber mobile node via a single multicast logical link per second node (SGSN).

3. A method as claimed in claim 1 or 2, further comprising the steps of, at the or each second node (SGSN), identifying at least one third node (RNC) responsible for said at least one subscriber mobile node, and where a third node (RNC) serves multiple subscriber mobile nodes, forwarding said M-PDU from the second node (SGSN) to the or each third node (RNC) via a number of multicast logical links that is less than the number of subscriber mobile nodes of the multicast group served by each third node (RNC) respectively.

4. A method as claimed in claim 3, wherein said M-PDU is forwarded to the or each third node (RNC) responsible for said at least one subscriber mobile node via a single multicast logical link per third node (RNC).

5. A method as claimed in any preceding claim, further comprising the steps, upon receipt of said M-PDU at the first node (GGSN), of searching a database for records of multicast logical links maintained by the first node (GOSH) for a record - 47 that references the multicast address of said M-PDU.

6. A method as claimed in claim 5, wherein each record contains a list of multicast subscriber entries for a particular multicast group, each multicast subscriber entry containing a reference to a first active logical link associated with the subscriber mobile node of that entry, and wherein said reference is used to look up the first active logical link for each multicast subscriber entry and extract the identity of the responsible second node (SGSN).

lo

7. A method as claimed in claim 6, wherein said reference comprises the Network Service Access Point (NSAPI) and/or International Mobile Subscriber Identity (IMSI) and/or Tunnel Endpoint Identifier (TEID), and said first active logical link comprises the PDP context associated with said subscriber mobile node between the first node (GGSN) and the responsible second node (SGSN).

8. A method as claimed in any preceding claim, further comprising the steps of ! creating a list containing the identity of the or each second node (SGSN) responsible for said at least one subscriber mobile node, removing duplicate identities from said list, and replicating and forwarding said M-PDU to the or each second node (SGSN) remaining on the list.

9. A method as claimed in any of claims 5 to 8, wherein a GGSN multicast identifier is used to encapsulate said M-PDU and forward it to the or each responsible second node (SGSN), and each multicast logical link is associated with one of said records.

10. A method as claimed in claim 9, wherein said GGSN multicast identifier includes a first Multicast-Tunnel Endpoint Identifier (M-TEID) calculated from the multicast address of the M-PDU, and said record is a multicast PDP (M-PDP) context.

11. A method as claimed in any preceding claim, further comprising the steps, upon receipt of said M-PDI] the or each second node (SGSN), of searching a database for records of multicast logical links maintained by the second node (SGSN) with the GGSN for a record associated with said MPDU. - 48

12. A method as claimed in claim 11, wherein said search is performed using the GGSN multicast identifier (or first M-TEID) associated with the M-PDU.

s

13. A method as claimed in claim I I or 12, wherein each record contains a list of multicast subscriber entries for a particular multicast group, each multicast subscriber entry containing a reference to a second active logical link associated with the subscriber mobile node of that entry, and wherein said reference is used to look up the second active logical link for each multicast subscriber entry and extract the lo identity of the responsible RNC, and to look up a mobility management record for the subscriber mobile node.

14. A method as claimed in claim 13, wherein said reference comprises a Transaction Identifier (TI) and/or International Mobile Subscriber Identity (IMSI) of the subscriber mobile node, and said second active logical link comprises the PDP context associated with said subscriber mobile node between the second node (SGSN) and the responsible RNC.

15. A method as claimed in claim 13 or 14, further comprising the step of so establishing a connection in the packet switched domain if the mobility management record indicates that the subscriber mobile node is not connected in that domain.

16. A method as claimed in any of claims 11 to 15, further comprising the steps of creating a list containing the identity of the or each RNC responsible for said at as least one subscriber mobile node, removing duplicate identities from said list and replicating and forwarding said MPDU to the or each RNC remaining on the list.

17. A method as claimed in any of claims 11 to 16, wherein a second node (SGSN) multicast identifier is used to encapsulate said M-PDU and forward it to the or each responsible RNC, and the or each multicast logical link is associated with said record.

18. A method as claimed in claim 17, wherein said second node (SGSN) multicast identifier includes a second Multicast-Tunnel Endpoint Identifier (second 3s M--lEID) calculated from the multicast address of the M-PD1J, and said record is a - 49 multicast PDP (M-PDP) context.

19. A method as claimed in any of claims 3 to 18, further comprising the steps, upon receipt of said M-PDU the or each RNC, of searching a database for records of multicast logical links maintained by the RNC with the second node (SGSN) for a record associated with said M-PDU.

20. A method as claimed in claim 19, wherein said search is performed using the second node (SGSN) multicast identifier (or second M-TEID) associated with the M o PDU.

21. A method as claimed in claim 19 or 20, wherein each record contains a list of multicast subscriber entries for a particular multicast group, each multicast subscriber entry containing a reference to a third active logical link associated with the subscriber mobile node of that entry, and wherein said reference is used to look up the third active logical link for each multicast subscriber entry and extract the identity thereof.

22. A method as claimed in claim 21, wherein said reference comprises a radio access bearer (RAB) ID and/or International Mobile Subscriber Identity (IMSI) and said third active logical link is an RAB context, the method further comprising the steps of replicating said M-PDU and forwarding to said subscriber mobile node over the wireless link.

23. A network node for use in a packet radio network, which network node comprises means for storing and executing computer executable instructions for performing a method or part of a method as claimed in any preceding claim.

24. A network node for use in a packet radio network, which network node comprises means for storing and executing computer executable instructions for performing either: ( I) any of the GGSN method steps of any of claims I, 2 and 5 to 10; or (2) any of the second node (SGSN) method steps of claims 3, 4 and 11 to 1 8; or (3) any of the RNC method steps of claims 19 to 22. - 50

25. A computer program comprising computer executable instructions for causing a computer to perform the method steps of any of claims 1, 2 and 5 to 10; any of claims 3, 4 and I 1 to 18; and/or any of claims 19 to 22.

26. A computer program as claimed in claim 25, embodied on a record medium, stored in a computer memory, embodied in a read-only memory or carried on an electrical carrier signal.