WO2005079100A1

WO2005079100A1 - System, arrangement and method relating to message handling within packet data communication

Info

Publication number: WO2005079100A1
Application number: PCT/SE2004/000195
Authority: WO
Inventors: Staffan Bonnier; Kaj Johansson; Anna Jernryd; Jan Scheurich; Åke JOHANSSON; Staffan Winell; Sjur Olav Braendeland
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2004-02-13
Filing date: 2004-02-13
Publication date: 2005-08-25

Abstract

The present invention relates to a packet data communication system comprising first (10) and second (20) packet data nodes communicating over a packet data communication protocol. Each first and second node comprises a number of processing arrangements (111, 112, 113; 211, 212, 213, 214) handling a number of communication contexts, wherein the communication contexts handled in a processing arrangement of a first node are/can be handled in different processing arrangements in one or more second packet data nodes. When, in a first packet data node (10), a processing arrangement is malfunctioning (112) or when it has deleted all, or a plurality of the communication contexts handled by it, a message containing the (IP) end point address of said processing arrangement is sent by said first packet data node (10) to at least one second packet data node (20), and if said second packet data node(s) (20) comprise(s) end-point mapping information about and can identify which of its processing arrangements (211, 212, 213, 214) are handling communication contexts with the indicated first packet data node end point address, said end-point mapping information is used to delete such communication contexts in the respective processing arrangements (211, 214) in said second packet data node(s) (20), otherwise the first packet data node (10) is, directly or indirectly, informed such that said first node (10) may use a conventional/default procedure to enable removal of said communication contexts in said second packet data node(s) (20).

Description

Title: SYSTEM, ARRANGEMENT AND METHOD RELATING TO MESSAGE HANDLING WITHIN PACKET DATA COMMUNICATION

FIELD OF THE INVENTION

The present invention relates to packet data communication. More specifically it relates to a packet data communications system comprising first and second packet data nodes communicating over a packet data communication protocol, wherein said first and second packet data nodes comprise a number of processing arrangements handling a number of communication contexts. A communication context handled in a processing arrangement of a first packet data node can be handled in different processing arrangements in one or more second packet data nodes. The invention also relates to such first and second packet data nodes and to a method in such a system.

STATE OF THE ART

In a packet data communication system, such as for example GPRS (GSM General Packet Radio Service) or UMTS (Universal Mobile Telecommunication System) , problems may arise when communication contexts, e.g. so called PDP contexts, are deactivated in one packet data node, e.g. by the node itself or by a mobile station served by the packet data node, since there is a risk that another, peer, second packet data node also handling said communication contexts might not be informed about the deactivation. This means that such communication contexts, particularly PDP contexts, which are deactivated or removed in one packet data node may still be "active" in another packet data node also handling the corresponding communication contexts, which means that, although they are removed in one node, and thus no more of any use, they will still occupy storing means, they may still load processing arrangements in second packet data nodes, addresses may still be allocated etc. Still further such a situation may have consequences for the subscribers since communication contexts might not be appropriately removed on charging records. This is particularly problematic when a plurality of communication contexts, or particularly PDP contexts, are deactivated or removed, for example when a first packet data node, e.g. an SGSN (Serving GPRS Support Node) deactivates a large number of PDP contexts, since there is this risk that PDP contexts might not be removed in the relevant GGSN (Gateway GPRS Support Node) due to abnormal situations, e.g. abnormal network situations.

An example of such a situation is when the path between a SGSN and an GGSN is down temporarily, which means that a GTP message from the SGSN towards the GGSN will not reach the GGSN. After a number of the retransmissions the SGSN will then stop transmitting and may internally deactivate the PDP contexts associated with the path whithout having informed the GGSN. Another example of such a situation is if one of the packet data nodes, e.g. SGSN or GGSN, supports GTP Echo Request which allows for detection of path failure, and deletes all PDP contexts associated to the path in question. The Echo Request procedure is described in 3GPP TS 29.060, section 7.2.1 and relates to a request which may be sent on a path to another GSN (GPRS Support Node) or to an RNC (Radio Network Controller) in order to find out if a peer GSN or RNC is alive. Echo Request messages may be sent for each path. Generally it is specified that an Echo Request shall not be sent more often than every 60s on each path. This is an optional functionality. A GSN shall reply with an Echo Response. An Echo Response (cf. 3GPP TS 29.060, 7.2.2) is a message that is sent as a response to a received Echo Request. If the other GSN node does not support Echo Request, i.e. the functionality for detection of path failure, it will actually not detect the path failure and it will therefore not delete any PDP contexts associated to the path. There may also be other situations, such as internal node problems, when a packet data node would need to inform another packet data node that a large number of PDP contexts have been removed. One example is when a processing arrangement or unit or a board in one packet data node has gone down or has restarted, and thus all communication contexts, particularly PDP contexts, handled by it are deleted. The communication contexts or PDP contexts handled by the processing arrangement may be handled by different processing arrangements in another (second) packet data node, or another GSN node. In addition thereto it may be handled by different second packet data nodes. Thus, if a processing arrangement in an SGSN goes down, the PDP contexts, possibly handled by several processing arrangements in several GGSNis, also have to be removed.

In GPRS/UMTS the control plane (signalling plane) handles GPRS mobility management functions, such as the attach procedure, routing area update and activation etc. of PDP contexts. The signalling between GSN nodes is performed by the GPRS control plane tunneling protocol GTP-C. The GTP-C signalling is associated with, but separate from, the GTP-U (GPRS Tunneling Protocol) for the user plane, i.e. for the traffic payload. GTP- C is the means by which the tunnels are established, used, managed and released and the path may be maintained by GTP Echo messages to ensure that a connection failure between GSN : s can be detected in a timely manner.

For the control plane a restart (and a loss of a number of PDP contexts) can be indicated through an increase of the restart counter.

For the user plane, however, the situation is more complex and different. According to the current standards restart counters are to be ignored in the user plane. Hence, there are no means for one packet data node to inform another packet data node that a plurality of communication contexts (e.g. PDP contexts) have been deactivated or removed in the first packet data node. From an SGSN it might be necessary to send up to a magnitude of 10 000 delete PDP context request messages, and from a GGSN it might be necessary to send up to a magnitude of 100 000 's such requests. With such an amount of signalling it will take a lot of time before all affected PDP contexts are removed and resources are made free in SGSN and GGSN respectively. Still further it is a waste of resources. Thus, when a processing arrangement in one of the first packet data nodes goes down or does not function such that a plurality or all communication contexts handled by it also are to be removed in peer, second, packet data nodes, this is a time consuming procedure as well as a resource consuming procedure, and still further it produces a lot of signalling which is not desirable.

SUMMARY OF THE INVENTION

What is needed is therefore a system as initally referred to through which recovery handling can be improved e.g. when a processing arrangement goes down or is malfunctioning or has to delete a plurality of communication contexts. Particularly a systems is needed through which the amount of recovery signalling required over the Gn (Gp) interface can be reduced. (The Gp interface is used between nodes of different PLMNs . ) Still further a system is needed through which recovery handling can be speeded up, i.e. a system through which consistency between packet data nodes handling the same communication contexts, particularly PDP contexts, can be improved, particularly speeded up and without wasting resources and bandwidth. Particularly a system is needed through which provides a procedure for one packet data node to inform another packet data node or other nodes that or all communication contexts handled by a processing arrangement, particularly a unit, a board or a handling board, are deleted, such that said other packet data node(s) are able to take the appropriate measures, i.e. delete communication contexts which are no longer active. Particularly a system is needed through which one packet data node in an easy manner can provide for deletion of all communication contexts or PDP contexts in one or more other packet data nodes with which it communicates over the Gn (Gp) interface. Most particularly a system is needed through which recovery handling can be improved, e.g. through reduced signalling and in a faster manner, when a user plane processing arrangement has deleted all communication contexts handled by it, when a processing arrangement is malfunctioning or taken down or when a path is down. Particularly a system is needed through which resources which are occupied for no use can be freed.

What is needed is therefor also a packet data node, for example an SGSN and/or a GGSN, through which one or more of the above mentioned objects can be achieved. Still further a method is needed through which one or more of the above mentioned objects can be achieved. Particularly a system, a node etc. is needed through which recovery handling can be improved also for the control plane, e.g. when a control plane processing arrangement is malfunctioning or down or a plurality of communication context thereon are inactivated, such that consistency is to be provided for in cooperating control plane processing arrangements in peer packet data nodes.

Therefore a system as initially referred to is provided in which, when a first packet data node processing arrangement is malfunctioning or has deleted (or is to delete) all, communication contexts handled by it, a message containing the end point address (e.g. IP end point address) of such processing arrangement is sent by said first packet data node to at least one peer second packet data node, whereby if said second packet data node(s) comprises end point mapping information about, and can identify, which of its processing arrangements are handling communication contexts with the indicated first packet data node end point address, said end point mapping information is used to delete such communication contexts in the respective processing arrangement in said second packet data node or nodes, otherwise the first packet data node is, directly or indirectly, informed, such that said first node may use a conventional or default procedure to enable removal of said communication contexts in said second packet data node (nodes) . Particularly such a conventional or default procedure comprises sending, for each communication context, a specific message related to that communication context.

Particularly the message relating to a request for deletion of a plurality of communication contexts is sent to the/those second packet data nodes handling the relevant communication contexts. The processing arrangements may comprise processors or plug-in cards or boards, particularly user plane (or control plane) handling boards. In a particular embodiment said first packet data node comprises a serving GPRS support node, SGSN, and said at least one second packet data node comprises a gateway GPRS support node, GGSN, and the communication contexts comprise PDP contexts. Alternatively the first packet data node comprises a GGSN, said at least one second packet data node comprising an SGSN. In one implementation said message comprises a specific or dedicated message. In another implementation the message comprises a predefined, existing message. Particularly said predefined, existing message is extended with information about the end point address of the (malfunctioning) processing arrangement having deleted a plurality of communication contexts in said first packet data node. The information may also somehow be "piggy-backed" onto an existing message.

Most particularly the malfunctioning processing arrangement of the first packet data node is/was responsible for user plane communication with user plane handling processing arrangements in one or more peer second packet data nodes for the concerned communication contexts. Most particularly the message is sent over the control plane, also denoted the signalling plane, even if it actually relates to a malfunctioning user plane handling board. Particularly the used communication protocol is GTP (GPRS Tunneling Protocol) , GTP-C for control plane signalling, and GTP-U for user plane communication. Particularly the defined existing message comprises a delete PDP context request message. Most particularly the delete PDP context request message is extended with the address (e.g. GTP-U IP address) of a malfunctioning processing arrangement. Most particularly the existing delete PDP context message comprises one, (or a limited number of) PDP contexts having resided on the malfunctioning processing arrangement, and which thus has/have to be removed in a processing arrangement or arrangements in one or more of the peer second packet data nodes. Particularly the accompanying PDP context is the first (or an arbitrary) PDP context that has to be deleted. The conventional delete, (here also called default) procedure particularly comprises sending one delete PDP context message from the first packet data node to the at least one second packet data node for each PDP context residing on/handled by the malfunctioning processing arrangement in the first packet data node.

In one particular embodiment of the invention an existing, defined information message sent from the first packet data node to the at least one second packet data node is used to establish whether the second packet data node supports deletion of a plurality of PDP context upon reception of a message indicating only the end point, end point, address of a malfunctioning processing arrangement, i.e the second packet data node comprises information about peer first node - second node addresses, and a defined, existing information response message sent from a second to a first packet data node is used to inform the first packet data node about the outcome of the establishment relating to whether the second packet data node supports such extended deletion of a plurality of PDP contexts or not. Particularly said existing, defined information message comprises a GTP Echo Request message, and the information response message comprise a GTP Echo Response message, the messages comprising a proprietary private extension of the first packet data node malfunctioning processing arrangement. In one implementation said message, i.e. the message requesting extended deletion of PDP contexts and containing the end point address of a malfunction processing arrangement, is only sent to such second packet data nodes which handle communication contexts handled by the malfunctioning processing arrangement. Alternatively the message is sent to all second packet data nodes with which said first data node is in communication or which it is able to communicate with.

Therefore a packet data node is also provided, which is used in the packet data communication system, and which comprises a number of processing arrangements, as initially referred to, which further comprises means for, when a processing arrangement is malfunctioning such that all communication contexts handled by it, are removed sending a message containing the end point address of said first processing arrangement to a second packet data node to allow said second packet data node to remove all communication contexts associated to that end point address, and in that it comprises means for informing a second packet data node using a conventional delete procedure if said second packet data node is not capable of removing/deleting a plurality of communication contexts based on said message.

The processing arrangement particularly comprises a processor, a plug-in card or a board on a node, which comprises an SGSN or a GGSN. The message particularly comprises a specific, dedicated message. Alternatively said means for sending a message uses an existing, defined message. The message is particularly sent over the control plane for mobility management using the GTP-C protocol, even if the malfunctioning processing arrangement particularly handles user plane communication contexts, using the user plane protocol GTP-U. The defined existing message particularly comprises a delete PDP context message which even more particularly is extended with a end point address of a malfunctioning processing arrangement and further it particularly comprises at least one PDP context having resided on or been handled by the malfunctioning processing arrangement. As referred to above, the conventional delete procedure particularly comprises sending a delete PDP context message from a first packet data node to a second packet data node for each PDP context having resided on or been handled by the malfunctioning processing arrangement.

In one particular implementation an existing, defined information message is sent to a second packet data node to establish whether the second packet data node supports deletion of a plurality of PDP contexts upon reception of said message indicating the end point address of a malfunctioning processing arrangement. Said existing information message particularly comprises a GTP Echo Request message, and a packet data node, upon receiving a positive GTP Echo Response message from a second packet data node, sends said existing, defined (request) message to said second node, whereas, upon reception of a negative Echo Response message from a second node, optionally uses the conventional delete (default) procedure. Even more particularly received GTP Echo Response messages are used to store information, e.g. in a table or similar, about second packet data node supporting/not supporting the extended deletion of a plurality of PDP contexts based on a message in the following also denoted an extended delete PDP Context Request message including the end point address of a malfunctioning processing arrangement. Particularly the message, i.e. the message requesting extended deletion of communication contexts and containing the end point address of a malfunctioning processing arrangement, is sent to all second packet data nodes or alternative only to those handling communication contexts also handled by said malfunctioning arrangement. According to the invention it is also provided for a packet data node which comprises means for, upon reception, from another (first) packet data node with processing means handling communicating contexts handled by a number of processing arrangements in the packet data node, of a message comprising the end point address of a malfunctioning processing arrangement in said other (first) packet data node, using said end point address to establish which processing arrangements that are handling the communication contexts also handled by the malfunctioning processing arrangement in said packet data node, and for deleting/removing such communication contexts.

In one implementation the packet data node comprises a GGSN. Alternatively it comprises an SGSN. Most particularly the packet data node comprises holding means, e.g tables, which are built up with information relating to which processing arrangements that handle communication contexts with given end point addresses of other (first) packet data nodes, such that it can be established, for each communication context, by which specific peer processing arrangement it is handled, i.e. that it comprises peer end point information. Particularly said message is received in a processing arrangement handling control signalling, whereas it concerns one or more processing arrangements handling user plane communication, i.e. a use plane handling processing arrangement is malfunctioning or has gone down. A method as initially referred is therefore also provided, which comprises the steps of; sending a message from the first packet data node comprising the end point address of the malfunctioning processing arrangement to at least one second packet data node; using, in said second packet data node, the end point address to establish, if possible, which, if any, processing arrangements in said second packet data node that do handle communication contexts handled by the malfunctioning processing arrangement of the first packet data node; deleting, in respective concerned processing arrangements, said communication contexts, otherwise, the first packet data node may optionally use a conventional, delete procedure to provide for removal of the communication contexts in the second packet data node(s) which are handled by the malfunctioning processing arrangement of the first packet data node. The communication contexts are particularly PDP contexts, and the step of sending the message comprises first finding, in the first packet data node, at least one PDP context handled by the/a malfunctioning processing arrangement; sending an existing, defined message, e.g. a delete PDP Context Request, extended with the end point address of the malfunctioning processing arrangement, and including one, (or a limited number only) of said PDP contexts to a second packet data node. Particularly the malfunctioning processing arrangement handles user plane payload and the method comprises the step of; sending the extended delete PDP Context Request message over a protocol (GTP-C) handling control signalling.

In this application a malfunctioning processing arrangement is per definition taken to mean either a processing arrangement

(unit, board etc) which actually is taken down or similar, or a processing arrangement having to delete all (a plurality of) communication contexts for some reason e.g. that a path is down or similar.

BRIEF DESCRIPTION OF THE DRAWINGS The invention will in the following be further described, in a non-limiting manner, and with reference to the accompanying drawings, in which:

Fig. 1 is a schematical block diagram of a part of a packet data communications system with a first and a second packet data node and in which the inventive concept can be implemented,

Fig. 2 is a schematical block diagram of a first and a second packet data node in which the inventive concept can be implemented,

Fig. 3 is a schematical signalling diagram describing the procedure according to one embodiment in which a specific request message been introduced for the purposes of informing a second packet data node that a plurality of communication contexts should be deleted,

Fig. 4 is a signalling diagram illustrating one embodiment of a procedure in which an existing, defined message is used to request an extended deletion of a plurality of PDP contexts using one message only and wherein a second packet data node supports such functionality,

Fig. 5 is a signalling diagram similar to that in Fig. 4 but wherein the second packet data node does not support extended deletion of PDP contexts, and thus a conventional, defined procedure has to may be used, Fig. 6 is a signalling diagram in which the first packet data node comprises a GGSN and the second packet data node comprises an SGSN, Fig. 7 is a signalling diagram in which existing information messages are used in order to build up information in holding means in a first packet data node relating to which second packet data nodes that do support extended deletion of PDP contexts, Fig. 8 is a figure simular that of Fig. 7 with the difference that the second packet data node does not support extended deletion of PDP contexts, Fig. 9 is a flow diagram describing the procedure according to one implementation of the present invention, Fig. 10A shows a first table, table 1, used in the procedure of Fig. 9,

Fig. 10B shows a second table, table 2, used in the procedure described in Fig. 9, and Fig. 10C shows a third table, table 3, used in the procedure described in Fig. 9.

DETAILED DESCRIPTION OF THE INVENTION

Fig. 1 schematically illustrates a part of a communication system supporting communication of packet data, e.g. UMTS, in which a mobile station communicates with a core network comprising a first packet data node, here comprising an SGSN 10, which is in communication with a GGSN, more generally a second packet data node 20, over a radio access network. SGSN 10 here comprises a number of processing arrangements, particularly consisting of user plane UP board Hi with some end point address IP 1, UP board 11₂ with IP 2 as end point address and UP board 11₃ with IP 3 as end point address. In this application a processing arrangement means a processing unit, a board or card etc. SGSN 10 is in communication with one or more GGSN : s (only one, GGSN 20, illustrated in this figure) over the Gn interface using the GTP protocol, GTP-C for control plane signalling and GTP-U for user plane payload. The second packet data node GGSN 20 also comprises a number of user plane processing arrangements, here UP board 1 21ι, UP board 2 21₂, UP board 3 21₃ and UP board 4 21₄. It is here supposed that UP board 11₂ in SGSN 10 goes down and that thus all PDP contexts residing on it are removed. As referred to earlier in the application it can be a very large number of PDP contexts. It is supposed that these PDP contexts are handled by several processing arrangements, particularly UP boards, in one or more GGSNs; for reasons of simplicity it is supposed that all PDP contexts are handled by UP board 11₂ in SGSN are handled by UP boards in GGSN 20. However, the PDP contexts handled by one UP board in a first packet data node, SGSN 10, are not handled by one specific UP board in the second packet data node, or GGSN 20, but they are distributed among the boards in GGSN 20 (generally among different boards in several GGSN:s) .

It is here supposed that SGSN 10 sends a delete PDP context request comprising one PDP context to be removed, i.e. having resided on UP board 11₂, and the IP end point address of UP board 11₂, which here is supposed to be IP 2. The conventional delete PDP context request is according to the invention extended with the IP end point address of UP board 11₂. It is supposed that GGSN 20 comprises or has access to mapping information such that it is able establish which PDP contexts are handled by which UP boards of GGSN 20, and of course, that it supports extended deletion of a plurality of PDP contexts having a particular IP end point address of a first packet data node board (here IP 2) based on just one single request message. It is here supposed that PDP context Xi should be deleted which resides on UP board 1 21ι and that PDP contexts X₂, X₃ residing on UP board 4 21₄ should be deleted whereas UP boards 2, 3, 21₂, 21₃ do not handle any PDP contexts handled by UP board 11₂ in SGSN 10. Subsequently GGSN 20 sends a Delete PDP Context Response to SGSN 10 verifying that all PDP Contexts concerned are deleted, in this case PDP contexts Xi, X₂, X₃.

It should be clear that thousands of, or even up to hundreds of thousands of PDP contexts can be concerned, but for reasons of clarity only a few are shown in this figure. Particularly the Delete PDP Context Request as well as the Delete PDP Context Response are sent over GTP-C but they concern user plane (units) boards. However, it might also relate to control plane boards, the functioning is then slightly different as will be briefly discussed later on.

In this implementation it is supposed that SGSN 10 knows to which GGSN the extended Delete PDP Context Request has to be sent. In an alternative implementation SGSN 10 does not have this information, but sends the delete PDP context requests in their inventive, extended form to all GGSN:s with which it communicates. Although here referring to "boards", this may actually mean a processing unit etc. as well.

Fig. 2 schematically illustrates a first packet data node PDN 1

10' and a second packet data node PDN 2 20' . Particularly PDN 1 comprises an SGSN whereas PDN 2 comprises a GGSN. It may however also be the other way round, that PDN 1 comprises a GGSN and PDN 2 comprises an SGSN. However, PDN 1 or SGSN 10' here comprises PDN 1 control means 12 communicating with PDN 1 storing means 13 and a number of processing arrangements 11A, 11B, 11C which handle a number of PDP contexts. It supposed that the first processing means 11A has end point address IP 1 whereas processing arrangement 11B has end point address IP 2 and processing arrangement 11C has end point address IP 3. The control means particularly comprises the circuitry required for implementing the mobility functions of the node and in addition thereto comprises the functionality of sending extended Delete PDP Context Requests with end point address of a malfunctioning processing arrangement (unit etc.), e.g. processing arrangement 11A, 11B or 11C. In PDN 1 storing means 13, e.g. comprising a RAM (Random Access Memory) and/or a ROM (Read Only Memory) etc. are stored a plurality of constants and variables used by the control means 12 during operation of the network node. The storing means will also store permanent and temporary values of various system parameters and for example mobil station specific information relating to one or more mobile stations. It may also comprise protocols for initiating and controlling communication. The PDN 1 storing means 13 here also comprises data and/or instructions for carrying out the sending of extended Delete PDP Contexts Request messages etc. according to the inventive concept. Particularly it may build up and store data relating to which second packet data nodes that actually do support extended deletion of PDP contexts, i.e. deletion of a plurality PDP contexts based on one Delete PDP Context Request message extended with end point information for example through the sending of information messages and receipt of the responses thereto from second packet data nodes, as will be more thoroughly explained below. Storing means for storing such information' may also be provided as a separate storing means, i.e. PDN 1 storing means 13 may be a separate storing means only for holding such information that is necessary for carrying out the inventive concept. However, it should be clear that information about which second packet data nodes support the extended Delete PDP Context functionality is not necessary for the functioning of the inventive concept; extended Delete PDP Context Requests may still be sent out and the extended deletion will be performed by such nodes supporting the functionality, whereas the first packet data node somehow will be informed when a second packet data node does not support the functionality and then, optionally, use a conventional delete procedure to enable deletion of the relevant PDP contexts, particularly through sending one Delete PDP Context Request message for each PDP context that should be deleted. The first packet data node can be informed about whether another, second packet data node supports the extended deletion functionality or not e.g. through a message making clear that such a functionality is not supported through a predefined message as a response to a request for extended deletion, which thus indicates that extended deletion is not supported, or through a message used for another purpose but with information to that effect piggybacked on to it. The first packet data node can also be informed to that effect through implementation of a timer whereas when the timer expires and no confirmation has been received, this indicates that the second packet data node did not support the functionality or vice versa, or when no message has been received within a time period, or before the timer expires and a message is received, this indicates that the functionality is supported. This can be provided for in many different ways. PDN 2, particularly GGSN 20' also comprises PDN 2 control means 22, PDN 2 mapping (storing) means 23 and a number of processing arrangements 21A, 21B, 21C, 21D controlled by PDN 2 control means 22. PDN 2 mapping (storing) means 23 may comprise the conventional storing means of PDN 2 further comprising information about which PDP contexts that are handled by a processing arrangement in a first packet data node that are handled by which processing arrangements in the second packet data node 20'. Alternatively PDP 2 mapping (storing) means 23 can be a separate mapping and storing means used for that purpose only. Thus, when PDN 2 20', particularly the control means 22, has received an extended delete PDP Context Request with end point address information of a malfunctioning or taken down processing arrangement of PDN 1 10' , it will, in this implementation, send a Delete PDP Context Response comprising an acceptance or a non-acceptance depending on whether this functionality is supported or not, based on which PDN 1 10' then may base a decision as to whether all PDP contexts handled by a malfunctioning processing arrangement have been deleted or if it is necessary to send separate Delete PDP Context Request message for each PDP context handled by such an arrangement.

Fig. 3 is a very schematical signalling diagram in which messages are sent between an SGSN and a number of, here only two, GGSN:s, GGSN 1 and GGSN 2. In this embodiment a specific message has been generated or defined for requesting deletion of all communication contexts with a particular originating IP end point address XX, i.e. the end point of a malfunctioning processing arrangement. This message is sent, here, to GGSN 1 and to GGSN 2. It is here supposed that GGSN 1 and GGSN 2 both support such a functionality and each of them verifies with a deletion performed message to SGSN 1 (otherwise one or both of the nodes might respond with a message indicating that it does not support such a functionality, whereby an SGSN optionally may use a conventional delete procedure sending specific messages relating to each communication context concerned, i.e. having resided on a malfunction processing arrangement) . Also in this implementation with a specific, for the purpose, defined message, SGSN may be aware or not of which GGSNs that might be concerned, i.e. that handle PDP contexts to be removed and support such a functionality, or a message may just be sent to each GGSN with which the SGSN is in communication. It should be clear that the procedure would be substantially the same if the first packet data node was a GGSN and the second packet data node was an SGSN.

Fig. 4 is a signalling diagram describing an extremely advantageous implementation in which an existing, defined message is extended and used for the a purpose of requesting extended deletion of plural PDP contexts. Thus the existing Delete PDP Context Request message is extended with a new optional IE (Information Element), the end point address IE. In this embodiment SGSN sends a Delete PDP Context Request comprising a first PDP context having resided on a processing arrangement, which is malfunctioning or taken down, indicated by "first TEID", and the end point address, to a GGSN. It is here supposed that the GGSN supports the functionality of extended deletion of a plurality of PDP contexts and thus sends a Delete PDP Context Response message ("new cause"), which is an existing predefined message with a new cause code. Thus, if the end point address IE is present in the receiving second packet data node, i.e. here the GGSN, GGSN may internally remove all PDP contexts having this end point address stored as "SGSN address" (or "GGSN address in use" if the receiving node is a SGSN) in the PDP context information in the GGSN (or SGSN if the first node is a GGSN and the second node is an SGSN) . The information to the requesting node (here SGSN) as to whether the extended Delete PDP Context Request message is supported, may comprise as a new cause code "request accepted - all PDP contexts removed", which indicates that all concerned PDP contexts have been removed from the relevant processing arrangements in the second packet data node, which in Fig. 4 is a GGSN, but which however also might be an SGSN in case the first node is a GGSN.

Fig. 5 is a signalling diagram illustrating the procedure when a first packet data node, here SGSN, like in Fig. 4, sends an extended delete PDP Context Request message (including a first PDP context removed in the malfunctioning processing arrangement and the end point address) to a second packet data node, here GGSN, which does not support the functionality of extended deletion of PDP contexts. It is here supposed that GGSN responds with a Delete PDP Context Response message ("old cause") . Thus, if the old cause code "request accepted" is sent from GGSN to SGSN, which is a defined response, this will indicate to the requesting node, here SGSN, that the extended Delete PDP Context Request message is not supported and consequently indicating that not all concerned PDP contexts has been removed in the receiving node, here GGSN, but particularly only the first PDP context included in the delete PDP context request (first TEID) . This indicates to the first packet data node, i.e. the requesting node, here SGSN, that a conventional, default procedure may be initiated, and SGSN subsequently may send separate Delete PDP Context Request message for each PDP context to GGSN, i.e. the Delete PDP Context Request message ("second TEID") and so on, GGSN responds with a Delete PDP Context Response for each Delete PDP Context Request.

Through adding a new optional IE to the existing delete PDP context request message, the amount of signalling over the Gn interface can be minimised when recovering after a path failure or after internal node problems. Furthermore the time required for removing PDP contexts in one node which have been deleted in another node, after path failure, is reduced. Still further, the extension of the existing Delete PDP Context Request/Response messages will not result in any incompatibility problems for packet data nodes, or core nodes, that do not support the new information element (IE), since the new IE is optional.

Fig. 6 is a figure similar to Fig. 4 but with the difference that the first packet data node comprises an GGSN, i.e. the requesting node comprises a GGSN, whereas the second packet data node comprises an SGSN. Thus, in this case the GGSN sends a delete PDP context request message which is extended and includes information about a first PDP context to be removed, first TEID, and the new optional end point address IE, which indicates that all PDP contexts having this address stored as GGSN address in the PDP context information in the SGSN should be deleted. SGSN confirms that all corresponding PDP contexts have been removed by responding with a new cause code "request accepted - all PDP contexts removed" in the delete PDP context response message. In case SGSN does not support such extended deletion, c.f. corresponding case when the requesting node is a GGSN. The procedure may then be same as that described in Fig. 5. In an advantageous implementation of the invention, the in 3GPP TS 29.060, 7.2.1, 7.2.2, defined messages Echo Request and Echo Response are used to provide information that can be stored, particularly in tables, in an SGSN as to which peer SGSN/GGSN:s that support the extended delete PDP context functionality. Of course the functioning is .similar in the case a GGSN acts as a requesting node or a first packet data node. However, in Fig. 7 it is illustrated how an SGSN sends an Echo Request extended with parameter or a proprietary private extension to the GGSN which may respond with an Echo Response including the parameter

(or the proprietary private extension) to indicate that the particular GGSN supports the functionality of extended deletion of PDP contexts. This information may be collected and stored to produce a table about which particular GGSN:s support this functionality.

Fig. 8 illustrates a signalling diagram in which an SGSN sends an Echo Request extended with a parameter (or proprietary private extension information) to a GGSN. However, in this case the GGSN does not support the functionality and responds with an Echo Response, i.e a conventional Echo Response in which a parameter or proprietary private extension information is not provided. Thus SGSN will note that this particular GGSN does not support the functionality of extended deletion of PDP contexts. Of course also in this case the functioning will be the same if the requesting node is a GGSN etc.

Fig. 9 is a flow diagram illustrating the procedure according to one particular embodiment of the invention. It is here supposed that an UP (user plane) board or more generally a processing arrangement or unit, in a first packet data node, e.g. an SGSN, goes down, 100. (It is here supposed that the packet data node has information as to whether peer packet data nodes support the extended PDP context functionality or not, which is saved in table 3, c.f. Fig. IOC.) Thus, when a UP processing arrangement or unit or board has gone down, it is examined whether any PDP contexts did reside on that board using table 1, c.f. Fig. 10A, 101. If not, there is no problem since no PDP contexts in a peer packet data node will have to be removed. However, if it is established that PDP contexts actually did reside on the malfunctioning UP board, a first PDP context having resided on that board is found using table 1, 102. Alternatively an arbitrary PDP context having resided on that board may be found or selected. It is now established on which external second packet data nodes or GGSN:s corresponding contexts have to be removed, using table 2, 103. Table 2 is illustrated in Fig. 10B. Fig. 10B contains information about, for each PDP context, which is the GGSN GTP-C IP address, i.e. here the control plane address. It should be clear that the same GGSN may be found several times i.e. that several contexts in one and the same GGSN should be removed, then the messages is still only sent once. Table 1 in Fig. 10A illustrates for the PDP contexts residing on an SGSN the GTP-U end point address and it can be seen that PDP context 1, 4,..., n reside on a board or processing arrangement (unit) with end point address IP 11 whereas PDP contexts 2, 3,..., reside on a board with GTP-U address IP 12 in SGSN.

Thus, when the step relating to establishment on which external

(second) packet data nodes corresponding contexts have to be removed has been performed using table 2, it is established whether the second packet data node supports extended deletion using using table 3, 104. Table 3 as shown in Fig. 10B indicates for each external GGSN, here GGSN GTP-C IP addresses IP 21, IP 31, IP 41, IP 51, IP nl, in the field "support extended deletion ?" which initially is set to "To Be Defined". When the suggested private extension in GTP Echo Request messages is used, and the corresponding answer in GTP Echo Response from the peer GGSN, it is possible for SGSN to determine whether the external GGSN supports the extended delete PDP Context Request message or not, and then "yes" or "no" is stored respectively. For each external GGSN the field "Sent" is initially set to "no". If the external GGSN supports the extended delete PDP Context Request message, and if it has been sent to a GGSN, "yes" is stored. However, when all affected PDP contexts have been handled, the field is set to "no" again.

Thus, if it is established that the second packet data node supports extended deletion (104), it is established, again using table 3, if an extended Delete PDP Context Request already has been sent, 105. If not, an extended Delete PDP Context Request message is sent, 105A. Then it is examined whether all PDP contexts have been handled, 106. If not, the next PDP context is found using table 1, 106A, and the procedure is repeated from step 103 above. If however all PDP contexts have been handled, the field "sent ?" is set to "no" for all records in table 3, 107, and the procedure ends, 108. If, in step 104 it was established that the second packet data node does not support extended deletion of PDP contexts, the node may send ordinary delete PDP context requests to the node, 104A, which procedure is repeated until all PDP contexts have been handled, 106. In one particular implementation the situation is handled according to the inventive concept when a control plane processing arrangement, or board, goes down or restarts. As referred to earlier in the application, according to the state of the art such a situation is handled by sending an incremented restart counter, i.e. one node can inform another node of a restart using that one message. However, according to the invention, a new delete PDP context message could be introduced in the GTP protocol which is similar to the extended existing delete PDP context message. Such a message would not contain any TEID, but the IP end point address to the processing arrangement, or board, that is concerned.

The first (requesting) packet data node, e.g. SGSN, will then send this new delete PDP context message to all GGSN:s with which it communicates using a first or a second path, depending on which path is alive. The second (receiving) packet data node will then check the received end point address and determine whether any PDP contexts in the second packet data node, e.g. GGSN, need to be removed. Since the modified, new delete PDP Context Request message will be sent to all second packet data nodes, e.g. GGSN:s, the message would of course also be sent to a GGSN that for the time being has no PDP contexts associated to the IP end point address of concern. The second packet data node, GGSN, would then simply reject the message with an appropriate cause code. Thus, according to the invention, an approach similar to the one discussed more thoroughly with reference to the user plane could also be implemented for the control plane, i.e. a concept that is based on identifying which PDP contexts that have to be removed as determined by an identifier indicating where, i.e. on which processing arrangement or on which board they are stored or handled, instead of by there own identifier such as for example TEID, IMSI, P-TMSI etc. It should be clear that the invention can be varied in a number of ways without departing form the scope of the appended claims and that it is not limited to the specifically illustrated embodiments .

Claims

1. A packet data communication system comprising first and second packet data nodes communicating over a packet data communication protocol, each first and second node comprising a number of processing arrangements handling a number of communication contexts, wherein the communication contexts handled in a processing arrangement of a first node are/can be handled in different processing arrangements in one or more second packet data nodes, c h a r a c t e r i z e d i n that when, in a first packet data node, a processing arrangement is malfunctioning or when it has deleted all communication contexts handled by it, a message containing the (IP) end point address of said processing arrangement is sent by said first packet data node to at least one second packet data node, and in that if said second packet data node(s) comprise (s) end-point mapping information about and can identify which of its processing arrangements are handling communication contexts with the indicated first packet data node end point address, said end-point mapping information is used to delete such communication contexts in the respective processing arrangements in said second packet data node(s), otherwise the first packet data node is, directly or indirectly, informed such that said first node may use a conventional/default delete procedure to enable removal of said communication contexts in said second packet data node(s).

2. A packet data communication system according to claim 1, c h a r a c t e r i z e d i n that at least some of the processing arrangements comprise processors .

3. A packet data communication system according to claim 1 or 2, c h a r a c t e r i z e d i n that some of the processing arrangements comprise (plug in) cards or boards .

4. A packet data communication system according to any one of claims 1-3, c h a r a c t e r i z e d i n that the first packet data node comprises a Serving GPRS Support Node, SGSN, and in that said at least one second packet data node comprises a Gateway GPRS Support Node, GGSN, and in that the communication contexts comprise PDP contexts, or vice versa, that said first packet data node comprises a GGSN and in that said second packet data node(s) comprise (s) SGSN(s).

5. A packet data communication system according to clam 4, c h a r a c t e r i z e d i n that said message comprises a specific or dedicated message.

6. A packet data communication system according to claim 4, c h a r a c t e r i z e d i n that the message comprises a predefined, existing message.

7. A packet data communication system according to any one of the preceding claims, c h a r a c t e r i z e d i n that the malfunctioning processing arrangement of the first packet data node is/was responsible for the user plane communication with user plane handling processing arrangement (s) in the second packet data node for the concerned communication contexts .

8. A packet data communication system according to claim 7, c h a r a c t e r i z e d i n that the message is sent over the control (signalling) plane.

9. A packet data communication system according to claim 8, c h a r a c t e r i z e d i n that the communication protocol is GTP, i.e. GTP-C for control plane signalling and GTP-U for user plane communication.

10. A packet data communication system at least according to claim 6, c h a r a c t e r i z e d i n that the defined existing message comprises a Delete PDP Context.

11. A packet data communication system according to claim 10, c h a r a c t e r i z e d i n that the Delete PDP Context message is extended with the (GTP-U) end point address of the malfunctioning processing arrangement and comprises one or a limited number only of PDP context (s) having resided on the malfunctioning processing arrangement.

12. A packet data communication system according to claim 10, c h a r a c t e r i z e d i n that the conventional delete procedure comprises sending a Delete PDP Context message from the first packet data node to the at least one second packet data node for each PDP context residing on/ handled by the malfunctioning processing arrangement.

13. A packet data communication system at least according to claim 6, c h a r a c t e r i z e d i n that an existing, defined information message from the first packet data node to the at least one second packet data node is used to establish whether the second packet data node supports deletion of a plurality of PDP contexts (extended deletion) upon reception of a message indicating only the end point address of a malfunctioning processing arrangement, (i.e. if the second packet data node comprises information about peer first node - second node addresses), and in that a defined, existing information response message from a second to the first packet data node is used to inform the first packet data node about the outcome of the establishment relating to whether the second packet data node supports such extended deletion of a plurality of PDP contexts.

14. A packet data communication system according to claim 13, c h a r a c t e r i z e d i n that the existing, defined information message for establishing whether the second node supports the extended PDP context deletion functionality comprises a GTP Echo Request message and in that the information response message comprises a GTP Echo Response message, the messages comprising a proprietary private extension of the malfunctioning first node processing arrangement.

15. A packet data communication system according to any one of claims 1-3, c h a r a c t e r i z e d i n that the first packet data node comprises a GGSN and in that the second packet data node comprises SGSN.

16. A packet data communication system according to any one of the preceding claims, c h a r a c t e r i z e d i n that said message only is sent to such second packet data node(s) that handle communication contexts handled by the malfunctioning processing arrangement.

17. A packet data communication system according to any one of claims 1-15, c h a r a c t e r i z e d i n that said message is sent to all second packet data nodes with which the first packet data node is in communication or able to communicate with.

18. A packet data node used in a packet data communication system and comprising a number of processing arrangements, each of which handling a plurality of communication contexts, c h a r a c t e r i z e d i n that it comprises means for, when a processing arrangement malfunctions such that all communication contexts handled by it are removed, sending a message containing the end point address of said first processing arrangement to at least one second packet data node to allow for said second packet data node to delete/remove all communication contexts associated to that end point address, and in that it comprises means for informing a second packet data node using a conventional delete or a default procedure if a second packet data node is not capable of removing a plurality of communication contexts by means of said message.

19. A packet data node according to claim 18, c h a r a c t e r i z e d i n that the processing arrangement comprises a processor, a plug-in card or a board.

20. A packet data according to claim 18 or 19, c h a r a c t e r i z e d i n that it comprises a SGSN.

21. A packet data node according to claim 18 or 19, c h a r a c t e r i z e d i n that it comprises a GGSN.

22. A packet data node according to any one of claims 18-21, c h a r a c t e r i z e d i n that said message comprises a specific, dedicated message.

23. A packet data node according to any one of claims 17-21, c h a r a c t e r i z e d i n that said means for sending the message uses an existing, defined message .

24. A packet data node according to any one of claims 20-23, c h a r a c t e r i z e d . i n that the message is sent over the signalling (control) plane for mobility management using the signalling plane (control plane) protocol GTP-C, and in that the malfunctioning processing arrangement handles user plane communication contexts, using the user plane protocol GTP-U.

25. A packet data node at least according to claim 20, c h a r a c t e r i z e d i n that the defined, existing message comprises a Delete PDP Context Request message.

26. A packet data support node according to claim 25, c h a r a c t e r i z e d i n that the Delete PDP Context Request message is extended with the (GTP-U) end-point address of the malfunctioning processing arrangement and comprises at least one PDP context having resided/been handled by the malfunctioning processing arrangement.

27. A packet data node according to claim 25 or 26, c h a r a c t e r i z e d i n that the conventional delete or default procedure comprises sending a Delete PDP Context Request message from the first packet data node to the second packet data node for each PDP context residing on/ handled by the malfunctioning processing arrangement .

28. A packet data node according to claim 25, 26, c h a r a c t e r i z e d i n that an existing, defined information message is sent to a second packet data node to establish whether the second packet data node supports deletion of a plurality of PDP contexts upon reception of said message indicating the end point address of a processing arrangement.

29. A packet data node according to claim 28, c h a r a c t e r i z e d i n that the existing information message comprises a GTP Echo Request message and in that the packet data node upon receiving a positive GTP Echo Response message from a second packet data node sends said existing, predefined message to said second node, and upon reception of a negative Echo Response message from a second node uses the conventional delete or default procedure.

30. A packet data node according to claim 29, c h a r a c t e r i z e d i n that received GTP Echo Response messages are used to store information about second packet data nodes supporting/not supporting the extended deletion of a plurality of PDP contexts based on an extended Delete PDP Context Request message.

31. A packet data node according to any one of claims 18-30, c h a r a c t e r i z e d i n that a message is sent to all second packet data nodes or only to those handling communication contexts handled by said malfunctioning processing arrangement.

32. A packet data node used in a packet data communication system, comprising a number of processing arrangements handling a plurality of communication contexts, c h a r a c t e r i z e d i n that it comprises means for, upon reception, from another (first) packet data node with processing means handling communication contexts handled by a number of processing arrangements in the packet data node, of a message comprising the end point address of a malfunctioning processing arrangement in said other (first) packet data node, using said end point address to establish which processing arrangements handle the communication contexts also handled by the malfunctioning processing arrangement, in said packet data node, and for deleting/removing such communication contexts.

33. A packet data node according to claim 32, c h a r a c t e r i z e d i n that it comprises a GGSN or an SGSN.

34. A packet data node according to claim 32 or 33, c h a r a c t e r i z e d i n that it comprises holding means or tables with information relating to which processing arrangements that handle communication contexts with given end point addresses of other, first, packet data nodes, such that it can be established, for each communication context, by which specific processing arrangement it is handled.

35. A packet data node according to claim 34, c h a r a c t e r i z e d i n that said message is received in a processing arrangement handling control signalling but that it concerns processing arrangements handling user plane communication.

36. A method for, in a communications system supporting communication of packet data, removing/deleting communication contexts in at least one second packet data node when a processing arrangement handling said communication contexts in a first packet data node is malfunctioning, c h a r a c t e r i z e d i n that it comprises the steps of:

- sending a message from the first packet data node comprising the end point address of the malfunctioning processing arrangement to said at least one second packet data node,

- using, in the second packet data node, the end point address to establish, if possible, which processing arrangements in the second packet data node that are handling communication contexts handled by the malfunctioning processing arrangement of the first packet data node, then

- deleting, in the respective processing arrangements, said communication contexts, otherwise,

- optionally using a conventional delete or default procedure to provide for removal of communication contexts in the second packet data node.

37. A method according to claim 36, c h a r a c t e r i z e d i n that the communication contexts are PDP contexts, and in that the step of sending a message comprises:

- finding, in the first packet data node, at least one PDP context handled by the/a malfunctioning processing arrangement,

- sending an existing, defined message, Delete PDP Context Request, extended with the end point address of the malfunctioning processing arrangement and comprising one or a limited number only of said PDP contexts.

38. A method according to claim 37, c h a r a c t e r i z e d i n that the malfunctioning processing arrangement handles user plane payload and in that the method comprises the step of: - sending the extended Delete PDP Context Request over a protocol (GTP-C) handling control signalling.