EP1844603A1

EP1844603A1 - Method for securing the communication links and the associated charges in a redundant communication network

Info

Publication number: EP1844603A1
Application number: EP05822337A
Authority: EP
Inventors: Klaus Hoffmann
Original assignee: Nokia Siemens Networks GmbH and Co KG
Current assignee: Nokia Solutions and Networks GmbH and Co KG
Priority date: 2005-01-24
Filing date: 2005-12-23
Publication date: 2007-10-17
Also published as: WO2006079411A1; DE102005007419A1; US20080130487A1

Abstract

The invention relates to a method for securing the communication links and the associated charges in a redundantly designed communication network (1) in which terminals (7.1 to 7.x, 11, 12) communicate via switches (2), preferably an IP bearer, and via hardware units (14, 15) by means of messages (13). According to the inventive method, proper functioning of the terminals (7.1 to 7.x, 11, 12) and/or the switch (2) and/or the hardware units (14, 15) is monitored using a monitoring function, and the functional hardware units (15) take over the physical functions of failed hardware units (14) in case of a failure (14.1) of one or several hardware units (14, 15). The functional hardware units (15) transmit a message (17) to the involved terminals (7.1 to 7.x, 11, 12) while additionally establishing that the monitoring function is performed by the still functional hardware units (15) immediately after taking over the physical functions. Furthermore, a flag from one of the failed hardware units (14) is transmitted to one of the functional hardware units (15) during an on-going transaction such that surcharges for said transaction are avoided.

Description

description

Method for securing the communication connections and the associated charging in a redundant communication network

The invention relates to a method for securing the kommunikationsverbindungen and the associated Vergebührungen in a redundant communication network, communicate with the terminals via mediators, preferably an IP bearer, by means of messages, with a monitoring function, the correct function of the terminals and / or the hardware units are monitored and in case of failure of one or more hardware units, the still functioning hardware units take over the physical functions of the failed hardware units.

Through the introduction of MGC-MGC communication (= MGC) with the application of the favorable bearer technology, such as Internet Protocol (= IP), the communication or traffic channel is switched through for communication In the cases in which a resolution or a separation from the connection setup, medium setup or bearer setup is carried out, ie in the case of a resolution or a separation between the communication terminal and (data) transmitter, several standardized methods are currently in use in the case of a dissolution or a disconnection from the connection establishment try to maintain the services in the telecommunications network.

For example, there is currently the ITU-T standard (= International Telecommunication Union - Telecomunication Stan- dardization Sector) Q .1902.x Bearer lndependent Call Control Capability Set 2 (= BICC CS2) with its own display function (= service indicator) during message transfer ( = Message Transfer Part; = MTP). This describes the Q765.5 bearer Application Transport (= BAT) for IP Bearer RTP (= Real Time Transport Protocol) as bearer technology, as it is possible, when separating a call (= call) and the bearer (= bearer), the end customer his usual services in the Te- provide telecommunications network.

As a further development, in the meantime the RFC 3261 (= Session Initiation Protocol = SIP) and the RFC 3204 (ISUP MIME Type) have emerged as standard in IETF (= Internet Engineering Task Force), which supports the tunnel transport of ISUP (= ISDN User Part). Messages allowed in Session Initiation Protocol messages.

As an additional standard, the RFC 2976 (INFO Method) was adopted, which allows to transport ISUP messages that could not be mapped to the messages defined by the RFC 2543 or RFC 3261.

As the NGN (= Next Generation Network) architecture becomes more widely accepted, the solutions to securing the availability of the associated network devices to ensure communication services and to provide secured billing data are becoming increasingly important, even in the event of hardware failure. In particular, the grid operators expect to secure the previously known

Functionalities even with hardware failures highly centralized hardware devices that provide the signaling protocols between multiple MGC s and corresponding terminals. In addition, in particular, failure scenarios are of considerable importance, which, ignoring the phenomena that occur, lead to "stuck resources." This is important because resources of the network are incorrectly no longer available for new assignments, resulting in a loss of business for the operator of the network , The Session Initiation Protocol for RFC3261 in particular places increased demands on the securing of a call (= calls), so that there the data relevant for the call, which are negotiated dynamically according to standard during call routing, and accordingly must be restored in the event of a failure, is added Do not get lost in this case. At the same time, however, there is still the requirement for controlling the resources in the network that in this case too it is ensured that the call itself and the billing are not interrupted and can also be correctly re-released or released.

Currently in communication systems, for example, the hiE9200 of the Applicant, as long as no failure took place, the Session Initiation Protocol due to the Session Timer Draft the other side using a monitoring function, for example, by re-INVITE with the Session Description Protocol monitored to the connection and the If necessary, stop charging if the other side has failed.

The SDP (= Session Description Protocol in this case includes the exact description of the properties of the currently used RTP bearer, for example the iP address, the RTP port, the used CODEC s, also called payload types, the state of the echo canceler, the state of the bearer, the SDP version counter and more.

This requires, in particular for both network units involved, such as the terminal and data transmitter, that they also have to additionally restore this session description protocol data in the event of a hardware failure for full support on the replacement hardware. In this way, in particular the preventive provision of storage space and additional computer capacity / time or processor time for securing and restoring these data on the replacement hardware is necessary in order to fully support the currently implemented procedure. If this industry standard (SIP session timer procedure) is not taken into account after a hardware failure, into account, so a stable Cail would unnecessarily triggered when the corresponding call data perfect as ^¬ can not be derhergestellt. A stable call is a call which, by lifting the telephone receiver, reaches the state: "subscriber has answered" and no other feature is activated, such as call hold or other call data has been lost and SIP session timer re-INVITE can no longer be answered, since in particular the session description protocol in the session initiation protocol is used to control functions such as call hold, bearer redirection, CODEC switchover of the bearer this means the unnecessary provision of storage and computational capacity for a stable calendar that does not really need this storage and computational capacity.

The RFC 3261 (= Session Initiation Protocol = SIP) introduces a clear separation between a SIP call processing application and the pure SIP transport function. Modern z. B. Software based architectures provide exactly this separation between application and signaling transport, such. B. in the communication systems hiQ6200 and hiQ9200 of the applicant. Particularly in the case of an SMP (simple symmetry processor) architecture, several SIP applications have interfaces to a central SIP transport function or location. Usually, transport functional parts are provided by third party manufacturers (OEM) or a software development unit of the applicant and incorporated into the products.

First solutions for saving a stable connection and maintaining proper charging of this stable connection are established and described in practice. Of major importance is the problem associated with the use of an encapsulated SIP transport layer. In particular, the SIP transport layer keeps a record of whether a response to a sent message exists between a hardware unit of the network (transport part) and a terminal has been received and sends the message again after expiration of a timer-controlled period according to RFC3261, chapter 17.1.2.2, if this answer is pending. In particular, the SIP application is also informed if the answer is completely absent, so that the SIP application is left to proceed, such. B. a trigger or another attempt to another target, etc.

The architecture used and the use of products from third-party manufacturers in the area of the SIP transport layer make it impossible for the network manufacturers - as the applicant - to know structures of the pure SIP transport part in detail, in order to duplicate them - ie. a duplication of the active page to the page not yet active at that time - the data on one

Standby page (in case of failure of the whole unit and thus also failure of the software and the associated data of the transaction of the transport part) for the transport part. Furthermore, a single network manufacturer can have no influence on the structure of the transport part in order, for example, to be able to seamlessly integrate the transport part into the own software-based structure and architecture, because manufacturers of the transport function offer as much software as possible for all potential network manufacturers. This makes it impossible for the network manufacturer to restore states of the transport part on a redundant hardware unit. Nevertheless, the network manufacturer must guarantee the telecommunications service provider the efficient use of its network, such as: B. in the sense of no hanging of resources.

The basic approach for detecting and further treating hardware failures and the associated transfer of "call data" relevant data to a replacement unit is known from the prior art, whereby only the SIP application-specific and relevant portions are discussed Network unit easy be readjusted by network operators by "pulling" the failure unit.

Based on two hardware units of the SIP communication network, in which one fails and the other is still functional, the replacement solution of the failed hardware unit by the functioning hardware unit remains at a charging level for the telecommunications service provider or for the user of a terminal in conjunction with at least one of the two hardware units very questionable. If, in the case of an unstable call, a transaction is open in the event of a default, it is possible, for example, to B. if a billing message is lost, unwanted overbilling will occur.

It is therefore an object of the invention to provide a method for securing the communication connections and the associated charges in a communication network for connecting terminals, preferably in a SIP communication network, which provides the usual communication services in the event of hardware failure, but opposite the previously known standardized backup method is easier and with significantly lower storage and computing capacity feasible. At the same time as the hardware failure, a still existing transaction, eg. B. is triggered by a failure unit or simply to be taken into account, overcharges for this transaction are avoided.

This object is solved by the features of independent claim 1. Advantageous developments of the invention are the subject of the subordinate claims.

The inventor has recognized that in the case of the Standard RFC3261 at Session Initiation Protocol and in the case of RFC3264, the Session Desktop Protocol offer / answer and the SIP Session draft (= Session Timers in the Session Initiation Protocol = Drafting Protocol). ietf-sip-session-timer-13), the possibility to monitor the SIP remote site is available. In chapter 7.4 of: "Generating Subsequent Session Refresh Requests of the SIP Session Draft", the use of the UPDATE method in RFC3311 is possible without using the Session Description Protocol (SDP: RFC2327). Source: http: / / www, ietf. org / internet-drafts / draft-ietf-sip-session-timer-15. txt, whereby the content of this website is fully incorporated into this application.

In accordance with the invention, the inventor proposes the known method for securing the communication connections and the associated charging in a redundantly structured communication network, in which terminals are distributed via intermediaries, preferably an IP bearer, and via hardware units

Messages communicate, with a monitoring function, the correct function of the terminals and / or the mediator (2) and / or the hardware units is monitored and in case of failure of one or more hardware units, the still functioning hardware units take over the physical functions of the failed hardware units, to improve that immediately after taking over the physical functions, the functional hardware units transmit a message to the participating terminals and additionally specify that the monitoring function is performed by the still functioning hardware units. Furthermore, in the case of an existing transaction (in the case of so-called unstable calls), a license plate is transmitted from one or more of the failed hardware units to one or more of the functional hardware units, so that over-charging for this transaction is avoided.

This ensures that in case of failure of one or more hardware units, the existing or re-established communication links and the associated billing in a communication network, preferably a SIP communication network, continue to function properly and the usual communication services are still available to the communication participants.

The redundantly constructed communication network can be a SIP communication network and the transmitted messages are SIP messages.

The restoration of the affected call data which was previously necessary in case of (hardware) failure, for example via the session

Description Protocol, with the associated necessary use of memory and computing capacity, can be avoided by using the new method.

It is advantageous for the method if the terminals which receive a message from the functional hardware units return an answer to them. For example, the involved SIP terminal may send a 200 OK in response to the UPDATE. As a result, it can be determined in a simple manner whether the existing communication connection is actually affected by the failure of the hardware unit.

Furthermore, it is advantageous if the terminals and / or the hardware units are monitored by a SIP Session Timer (Session Timer Session Initiation Protocol). This provides a simple method of monitoring the SIP communication devices involved in the SIP system.

The SIP Session Timer monitoring function can determine whether the terminals or hardware components involved send or receive an INVITE or UPDATE message using the UPDATE message without SDP. This determines the role of the SIP endpoint. This is particularly advantageous since the other party no longer has to send a re-INVITE with the Session Description Protocol, which then in turn, in turn, with the no longer necessarily existing Session Description Protocol with all its aspects in the response to the re-INVITE would have to be answered. The effort to connect the new hardware unit with the previous terminal, after taking over the functions of the failed hardware unit is therefore kept smaller than previously in the new process.

In one embodiment of the method, the billing is performed by a SIP proxy, preferably a proxy server. In the event of failure of the SIP proxy, the message UPDATE can be sent to both communicating terminals after the physical functions have been taken over by the functional hardware units so that the call is not triggered. Where the page waiting to receive the periodic re-INVITE / UPDATE will trigger the call when the message is received.

In the new method, billing may be further performed or stopped depending on the response of the terminals if no response comes from the terminals. If, for example, a reply to a message of a functional hardware unit to the participating terminal with a negative response, it can be concluded that this page is still functional and the call and the charge can continue to run.

In summary, stable and unstable calls and their billing in the event of a hardware failure are detected clearly, correctly and without loss, and appropriate measures (triggering of the call, termination of billing, etc.) are initiated.

In the following the invention with reference to the preferred embodiments with reference to the figures will be described in detail, it being understood that only the essential elements for the immediate understanding of the invention elements are shown. Here, the following reference numerals are used: 1: SIP communication network; 2: IP bearer / transmitter; 3: Te telecommunications system / hiGlOOO; 4: TX (= Transit Exchange); 5: LE (= Local Exchange); 6: PSTN (Public Switched Telephone Network); 7.1-7.X: communication terminal / telephone; 8: Media node / hiQ9200; 9: CMN Call Mediation Node from BICC ITU-T Q .1901, - 10: SIP Proxy; 11: SIP terminal; 12: computer; 13: Transfer of SIP messages; 14: first hardware unit; 14.1: failure of the first hardware unit; 15: second hardware unit; 16: redundant link first and second hard ware ^¬ unit; 17: message / UPDATE; 18: Reply to Detection UPDATE / 200 OK.

They show in detail:

Figure 1: Schematic structure of a SIP Kommunikationsnet- zes;

Figure 2: schematic diagram showing the failure of a hardware unit and the subsequent steps explained in the new method.

FIG. 1 shows a schematic structure of a SIP communication network 1. In this SIP communication network 1, communication terminals 7.1-7.X, preferably simple telephone sets, are connected to one another via an intermediary, here an IP bearer 2. The communication terminals 7.1-7. X are connected to Public Switched Telephone Networks 6. However, computers 12 can also communicate with one another via this SIP communication network 1 and the transfer of SIP messages 13 taking place therein. The invention also covers networks in which SIP terminals are connected directly to a SIP proxy in a pure SIP domain, without a public telecommunications network PSTN 6.

The network operator would also like to ensure the failure of one or more hardware units of the SIP communication network 1, so that on the one hand the billing for the existing communication connections can be billed correctly and continue. On the other hand, the users of the SIP Communication network 1 despite failure the usual services without waiting time are available. For this purpose, a new simple method is presented, which enables the securing of the communication connections and the associated billing in a SIP communication network.

FIG. 2 shows a schematic diagram in which a failure 14.1 of a hardware unit, in this case the first hardware unit 14, is shown, which, for example, is shown in FIG. Outwardly as a unit within units 8 or 9, for example, communicating via the SIP protocol (eg, the MGCP could run between units 8 and 3). The failure 14.1 of the first hardware unit 14 is represented by the X symbol. Furthermore, FIG. 2 schematically shows how the second hardware unit 15 performs the tasks of the failed first hardware unit 14 and which steps are initiated for this purpose in the new method.

For security reasons, the hardware units 14 and 15 in a communication network have a redundant connection 16 with one another, so that a takeover of the function of the failed hardware unit 14 by the still functional hardware unit 15 is made possible. In the process, the identifier - Z .B. information about the status of the transaction - in case of an existing transaction (ie an unstable call eg relative to one of the terminals 7.1-7.X, 11, 12 or to any transaction-triggering failure unit (intermediary, hardware unit, cookies) Server, etc) and for which call the transaction is now reported to the functional hardware unit 15) is transmitted from the failed hardware units 14 to the functional hardware units 15 (the license plate is transported internally by a unit 14 to the further unit 15, so to speak) ( not visible from the outside) so that over-charging for this transaction is avoided, so that the working hardware unit 15 knows that there is still one open transaction at a call. With the transfer to the functional hardware unit 15, the call is triggered preventively, since a transaction has started on the failed hardware unit 14. However, the answer does not come to the application in the functional hardware unit 15, since the required data is not available in the transport part. In summary, in this case - in the case of an existing transaction - an unstable SIP call is controlled and triggered, and charging is terminated.

Methods and methods for detecting hardware failures and the further handling of hardware failures or the associated transfer of relevant data to the replacement hardware unit are already known from the prior art. In the new method, the Session Initiation Protocol (= SIP) relevant shares are preferably used.

In the event of failure 14.1 of the first hardware unit 14, the second hardware unit 15 will assume the function of the first hardware unit 14 in accordance with the redundant structure of the communication network. So far, the first hardware unit 14 was connected to a SIP terminal 11, such as a telephone and / or a computer. The connection of the first hardware unit 14 to the SIP terminal 11 is not shown in FIG. After failure 14.1 of the first hardware unit 14, the second hardware unit 15 is connected to the SIP terminal 11 and communicate with it.

After taking over the physical function (s) of the first hardware unit 14, the second hardware unit 15 in the new method sends a message 17 to the SIP terminal 11, here a SIP UPDATE. The SIP UPDATE is a SIP message or a possible method, which is defined in RFC3311 and is not excluded in the SIP Session Timer draft, which can indicate a change of the SIP call without omitting the Session Description Protocol of the communication. onsnetzwerkes to use. The message 17 may include the additional stipulation that the SIP session timer monitoring function is performed immediately from here, ie from the second hardware unit 15.

The SIP session timer monitoring function can specify which of the two parties involved, ie the second hardware unit 15 or the SIP terminal 11 should send the messages INVITE or UPDATE to determine the readiness and presence of the other party. On the one hand, the message INVITE is a SIP message which can establish a connection or, on the other hand, makes it possible for an existing stable connection to change the connection data as re-INVITE. It can also be used for the SIP Session Timer procedure.

The determination that the second hardware unit 15 will be the new communication partner of the SIP terminal 11 can thus be determined independently of the previous history on the first hardware unit 14 by the second hardware unit 15. This is particularly advantageous, as it means that the other party can no longer send a re-INVITE with the Session Description Protocol, which then in turn, with the not necessarily existing Session Description Protocol with all its aspects in the response 18, here a 200 OK to re-INVITE, would have to be answered.

According to the invention, the SIP partner 11 who receives the message 17, here an UPDATE, answers with the reply 18, here a 200 OK. This is the according to RFC3261 SIP standard positive response to a SIP message, here positive response to UPDATE. In this way, both the second hardware unit 15 and the SIP terminal 11 know that the call or the connection is in order and the charging and the call need not be terminated. This is especially the case because despite failure 14.1 of the first hard- Wareeinheit 14, which provides only the SIP signaling, the associated communication network is still very functional, and the communication participants can still speak or communicate with each other, and the failure 14.1 of the first hardware unit 15 has no effect.

If the other party answers the message / UPDATE 17 with a negative answer 18, the second hardware unit 2 will judge this reaction as an acknowledgment, after which the other party is still functional, and the call and billing can continue.

In the case of a SIP proxy failure, which, for example, makes the charging, then, according to the invention, the transmission of the UPDATE is to be carried out to both sides of the connection.

In particular, it should be noted that the solution proposed for SIP can also be transmitted for the protocols MGCP (according to RFC2705) and MEGACO (ITU-T H .248), since basically the same problem occurs there.

It is understood that the abovementioned features of the invention can be used not only in the respectively specified combination but also in other combinations or in isolation, without departing from the scope of the invention.

The following abbreviations were used:

BAT Bearer Application Transport

Bearer transmitter

BICC Bearer lndependent Call Control

Call Call CMN Call Mediation Node

CODEC Coding Decoding

IETF Internet Engineering Task Force IP Internet Protocol

ISDN Integrated Services Digital Network = service integrating digital telecommunication network

ISUP ISDN User Part

ITU-T International Telecommunication Union - Telecommu- nication Standardization Sector

LE Local Exchange

MG Media Getaway

MGC ^'s Media Getaway Communication

MTP message transfer protocol

NGN Next Generation Network

PSTN Public Switched Telecommunication Network

RFC Request For Comments

RTP Real Time Transport Protocol

SIP Session Initiation Protocol

SDP Session Description Protocol

TX Transit Exchange

Claims

claims

1. A method for securing the Koitimunikationsverbindungen and the associated Vergebührungen in a redundant communications network (1), in which terminals (7.1- 7.x, 11) via intermediaries (2), preferably an IP bearer, and hardware units (14 , 15) communicate by means of messages (13), with a monitoring function monitoring the correct functioning of the terminals (7.1-7.X, 11, 12) and / or the mediator (2) and / or the hardware units (14, 15) and in the event of failure (14.1) of one or more hardware units (14, 15), the functional hardware units (15) assume the physical functions of the failed hardware units (14), characterized in that immediately after the physical functions have been taken over, the functional hardware units (15) involved devices (7.1-7.X, 11, 12) transmit a message (17) and additionally specify that the Üb is performed by the functioning hardware units (15) and that in a transaction still in progress a license plate from one of the failed hardware unit (14) is transmitted to one of the functional hardware units (15), so that over-charging for this transaction is avoided.

2. Method according to the preceding claim 1, characterized in that as a redundantly constructed communication network (1) a SIP communication network is used and as messages SIP messages are transmitted.

3. The method according to any one of the preceding claims 1 and 2, characterized in that the terminals (7.1-7.X, 11, 12) having a message (17) get from the functional hardware units (15), this one return an answer (18).

4. The method according to any one of the preceding claims 1 to 3, dadurchgeke nn records that the terminals (7.1-7.X, 11, 12) and / or the hardware units (14, 15) by a SIP session timer (session timer in the session Initiation Protocol) are monitored.

5. The method according to the preceding claim 4, since you rchgeke zeic hn et that the SIP session timer monitoring function determines whether the participating terminals (7.1-7.X, 11, 12) or the hardware components (14, 15) send or receive an INVITE or UPDATE message using the UPDATE message without SDP.

6. The method according to any one of the preceding claims 1 to 5, characterized in that a billing is performed by a SIP proxy (10) and in case of failure of the SIP proxy's message (17) to both communicating terminals (7.1-7.X, 11, 12) is sent.

7. The method according to any one of the preceding claims 1 to 6, characterized in that the billing depending on the response (18) of the terminals (7.1-7.x, 11, 12) is performed or terminated if no answer came and the CaIl is terminated.

8. The method according to any one of the preceding claims 1 to 7, characterized in that in an existing transaction with one of Terminals (7.1-7.X, 11, 12) via a failure unit triggered a CaIl and the corresponding billing is stopped.