WO2013116971A1

WO2013116971A1 - Method for a network node involved in handling of call connections, whereby mutual call connection requests are received

Info

Publication number: WO2013116971A1
Application number: PCT/CN2012/070883
Authority: WO
Inventors: Chunbo Wang; Remi TASSING; Wenliang Xu
Original assignee: Telefonaktiebolaget L M Ericsson (Publ)
Priority date: 2012-02-06
Filing date: 2012-02-06
Publication date: 2013-08-15

Abstract

The invention pertains to a method for a network node involved in handling of call connections, whereby mutual call connection requests are received. The network node receives a message indicating that a call towards a first party shall be established, whereby a reference allowing for identifying the calling second party is provided, and it receives a message indicating that another call towards the second party shall be established, whereby a reference allowing for identifying the calling first party is provided. The network node then determines whether the first party and the second party are both calling each other and decides whether the first party or the second party will be handled as originating party. Furthermore, the invention proposes a network node being enabled to process methods according to the invention.

Description

Method for a network node involved in handling of call connections, whereby mutual call connection requests are received

TELEFONAKTIEBOLAGET L M ERICSSON (PUBL)

Background

It is often experienced that in case two users are dialing each other almost at the same time, neither one can be connected through as both users will receive an indication that the respective called user is busy. It is also quite often that these users are trying again which will lead again to the same situation. This deadlock is overcome only if one of the users is dismissing to retry, thereby clearing a line and thereby allowing for a successful call by the persistent caller towards the dismissing user.

These deadlock situations are annoying for the users and also lead to a situation where a lot of signaling load is generated until a successful call may be established. Furthermore, as both users are busy not only for the actual call but also for the time consumed for the unsuccessful call attempts, both users waste time and may also not be available for other users.

Additionally, in case an attempted call is pertaining to an emergency, such waste of time may even be dangerous.

Summary It is object to obviate at least some of the above disadvantages and to provide an improved network node involved in handling of call connections, whereby mutual call connection requests are received, which avoids a deadlock of these mutual call connections and corresponding methods therefore.

Therefore, the invention proposes a method for a network node involved in handling of call connections, whereby mutual call connection requests are received. The network node receives a message indicating that a call towards a first party shall be established, whereby a reference allowing for identifying the calling second party is provided, and it receives a message indicating that another call towards the second party shall be established, whereby a reference allowing for identifying the calling first party is provided. The network node then determines whether the first party and the second party are both calling each other and decides whether the first party or the second party will be handled as originating party. A network node may be e.g. a Core Network Node.

Furthermore, the invention proposes a network node being enabled to process methods according to the invention. Said network node is adapted to be involved in handling of call connections, whereby mutual call connection requests are received. The network node comprises a receiving entity for receiving a message indicating that a call towards a first party shall be established, whereby a reference allowing for identifying the calling second party is provided, and for receiving a message indicating that another call towards the second party shall be established, whereby a reference allowing for identifying the calling first party is provided, and a determining entity for determining whether the first party and the second party are both calling each other, and for deciding whether the first party or the second party will be handled as originating party.

Further advantageous embodiments are subject to the dependent claims as well as the detailed description.

Brief description of the drawings

In the following the invention will be further detailed with respect to the figures.

Figure 1 is a block diagram illustrating embodiments of a set-up involving handling of busy callers, Figure 2 is a signaling diagram illustrating embodiments of method steps within a BICC environment,

Figure 3 is a signaling diagram illustrating embodiments of method steps within a SIP environment,

Figure 4 is a signaling diagram illustrating embodiments of method steps within an IMS environment,

Figure 5 is a signaling diagram illustrating embodiments of method steps within a PSTN environment,

Figure 6 is a flowchart illustrating steps in an embodiment of a network node, and

Figure 7 is a block diagram illustrating embodiments of a network node. Detailed description

Before embodiments of the invention are described in detail, it is to be understood that this invention is not limited to the particular component parts of the devices described or steps of the methods described as such devices and methods may vary. It is also to be understood that the terminology used herein is for purpose of describing particular embodiments only, and is not intended to be limiting. It must be noted that, as used in the specification and in the appended claims, the singular forms "a", "an" and "the" include singular and/or plural referents unless the context clearly indicates otherwise.

In Figure 1 a situation to be handled by network nodes is visualized. A network node may be part of a core network, and therefore it may also be denoted as a core network node. A subscriber may also be denoted as a user as a subscription may only be necessary for the operation of a certain type of network however has no influence on the operation of the invention. There, a first network node MSC-A receives a message by a user MS-A. The message is visualized by the incoming arrow having the indication CC Setup (CdPN=B). A second network node handling user MS-B receives also a message. The message is visualized by the incoming arrow having the indication CC Setup (CdPN=A). Here, user B is calling party A, called party number CdPN=A, while user A is calling user B, called party number CdPN=B. Suppose that MSC-A already tries to contact the MSC-B which is handling user B as called party of user A. This is indicated by an arrow from MSC-A towards MSC-B titled 1AM. A respective message is containing the called party number CdPN=B.

In an environment as described initially MSC-B would inform MSC-A that the called user B is busy as user B is currently trying to setup a call. The same would happen to user B as MSC-B on contacting MSC-A handling user A would inform MSC-B that user A is busy.

However, in the methods according to the invention the network node MSC-B receives a message 1AM indicating that a call towards a first party, called party number CdPN=B, shall be established, whereby a reference allowing for identifying the calling second party, calling party number CgPN=A, is provided, and the network node MSC-B receives also a CC-Setup message indicating that another call towards the second party, called party number CdPN=A, shall be established, whereby a reference allowing for identifying the calling first party, calling party number CgPN=B, is provided, i.e. the message comprises a reference from its sender MS-B.

The network node MSC-A receives a message 1AM indicating that a call towards a first party, here the called party number is CdPN=A, shall be established, whereby a reference allowing for identifying the calling second party, here the calling party number is CgPN=B, is provided, and the network node MSC-A had received also a CC-Setup message indicating that another call towards the second party, here the called party number is CdPN=B, shall be established, whereby a reference allowing for identifying the calling first party, calling party number CgPN=A, is provided, i.e. the message comprises a reference from its sender MS-A.

The Calling Party Number (CgPN) may be included in the 1AM or INVITE message but it may also be provided in other messages. However, in view of reduced network load, it is preferred that the calling party number is provided as early as possible.

In case a Calling Line Presentation Restriction is required by one of the users respectively one of the operators providing services to the users a network node CNN having said functionality should include CgPN in messages towards other network nodes involved in the call handling irrespective of this restriction.

In case a Calling Line Presentation Restriction is mandatory, a new Information Element may be foreseen carrying the Calling Party Number. Hence, both network nodes MSC-A and MSC-B may now detect that the users A and B are calling each other.

MSC-A knows from the CC-Setup that user A as sender of the CC-Setup is calling user B (CdPN=B) while MSC-A also knows from the received 1AM that user B (CgPN=B) is calling user A (CdPN=A).

MSC-B knows from the CC-Setup that user B as sender of the CC-Setup is calling user A (CdPN=A) while MSC-B also knows from the received 1AM that user A (CgPN=A) is calling user B (CdPN=B) as well.

Hence, both network nodes MSC-A and MSC-B involved in handling in handling of the mutual call connection requests may determine that the users call each other. Now that the network nodes MSC-A and MSC-B may have individually determined that the users are calling each other in mutual calls, both may decide whether the first party (A party) or the second party (B party) will be handled as originating party.

Now suppose that only one of the network nodes has issued a message 1AM indicating that a call towards from a first user towards another user shall be initiated while the other network node only has received a request from said another user to setup a call towards said first user.

E.g. MSC-A already issued a message 1AM indicating that a call shall be initiated towards B, and MSC- B has received the 1AM message as well as a CC Setup message by user B indicating to call user A, than MSC-B does not need to inform MSC-A of the call request but may just proceed with the call handling towards user B, i.e. in this case user A will be handled as mobile originating party while user B will be handled as mobile terminating party. I.e. MSC-A is informed by MSC-B that the 1AM is accepted, e.g. via an APM message. In this case MSC-A will not be aware of the mutual call attempts but assume that the call will be like any other call.

Note, as MSC-A does not need to detect a mutual call, MSC-A does not need to be enabled to proceed as MSC-B as long as within the message sent by MSC-A towards MSC-B there is a reference allowing for identifying the calling side.

Now, suppose that both network nodes MSC-A and MSC-B have issued a respective message 1AM indicating that a call towards another user shall be initiated. In this case both network nodes need to decide which part shall be mobile terminating side respectively the mobile originating side of a call. Although a negotiation thereof could have been envisaged, in order to decrease network load, both network nodes shall apply the same logic, thereby reducing signaling load and thereby also overall network load.

E.g. in the following we will assume that MSC-B is handling the terminating side of the call while MSC-A is handling the originating side of the call. MSC-B handling the terminating side and having already issued a message towards MSC-A indicating that user B wishes to setup a call towards user A may actively release the call leg by sending an appropriate message towards MSC-A. MSC-A handling the originating side but having received said message by MSC-B indicating that user B wishes to setup a call towards user A, receives the message indicating that the call leg initiated by MSC-B shall be released, and there upon releases the call leg and acknowledges the active release message.

However, depending on the actual implementation it may also be foreseen that MSC-A handling the originating side and MSC-B handling the terminating passively release, i.e. without exchange of any further information, the call leg initiated by MSC-B as both of them have independently determined their role as originating respectively terminating side and therefore know that a call leg initiated by the now terminating side shall be released.

In addition, MSC-B may issue a notification that user B is no longer busy even though the handling also allows that MSC-A assumes that user B is no longer busy with respect to the handling of the mutual call attempt. Now, as both network nodes MSC-A and MSC-B involved in handling in handling of the mutual call connection requests are primed the call processing may continue as if there would have been no mutual calls but only a single call where user A is calling user B.

By the process outlined above, it is possible to also ensure a successful call in case both network nodes have issued respective messages.

Note, both network nodes need to know in this case whether the other network node supports said handling.

Such information may be preconfigured via an operation and maintenance interface by the operator or it may be exchanged within information exchanges performed by the network nodes, e.g. core network nodes, or it may even be included as an information element within the call handling itself.

Now turning to determination of which side shall be the originating and which one the terminating side.

A versatile option is to base the determination on references allowing for indentifying the first and second party. In order not to burden specific regions and / or network operators, it may be foreseen that a predetermined algorithm is based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the references are compared with respect to one or more digits.

Suppose the following situation, a user A within a network having an operator identification of 171 and number 23456 is calling a user B having an operator identification of 161 and number 91999. If one would base the algorithm on all digits of the number and define the algorithm to compare the numbers and to select the higher number to be the originating side, than user A would with respect to pretty much all users in network B having the same or smaller number size be the originating side pushing the burden of caller fees towards him. The same would be true, if one would take only the users' number without the leading operator. Than user B would always be the originating side with respect to all users having the same or smaller number size. Hence choosing an algorithm also influences whether the algorithm is experienced as fair or not both from operator and from user perspective.

Therefore, if one is only taking some digits into account, e.g. the last 3 digits, the fairness is increased while the amount of computing efforts for decisions is reduced. Furthermore, in case the number size is different, a certain amount of numbers may be expected as a minimum set for user identification. Hence, taking a smaller set of numbers also allows for comparison of different sized numbers without any trouble.

E.g. one may base the decision on the last digit of the users' numbers omitting any country code and/or operator code and/or regional code as it may be foreseen with a respective numbering plan.

If one is taking more than the last digit into account, one may also foresee a comparison on a reversed scheme. I.e. if one is taking the last 4 numbers into account, e.g. user A having the number 23456 and user B having the number 991999 than one would take the digits 3456 for user A and 1999 for user B and revert the order to 6543 for user A and 9991 for user B and compare these numbers.

Now suppose that the references used for comparing still would be the same, i.e. both digits or digit sequences for user A and user B would be identical. Then, the decision may be based on other parameter such as time of receipt of the respective message indicating that a call towards a party shall be established and/or the overall length of the references allowing for indentifying the first and second party.

In case there would still be a match, a rare case, it may be foreseen to stop the handling and to have these users be handled just as before, i.e. both users will be signaled that the called user is busy. Now, in the following several types of networks will be highlighted where the above described handling may by example but not limited thereto be embodied. Further note, that the signaling is simplified and does not show all signaling but only the one which may be of relevance for the actual method.

BICC example Suppose that the network nodes are core network nodes of a communication network having support for BICC interfaces for call handling as shown in figure 2. There a subscriber A having number 123453 indicated as a Mobile Station MS-A issues a setup message towards its associated core network node MSC-A indicating the wish to set-up a call towards subscriber B having number 321654. MSC-A issues via BICC an 1AM message indicating that subscriber A wishes to initiate a call towards subscriber B. Said 1AM message may comprise a further information element BCC indicating that the MSC-A is supporting the handling of mutual calls.

MSC-B on receipt of the 1AM message checks with its associated visitor location register VL whether subscriber B is marked busy. Since subscriber B has issued a setup message as well, it is marked busy.

Now MSC-B determines whether subscriber A and subscriber B are trying to call each other. Now, MSC-B checks whether an 1AM message has been sent already towards MSC-A or not. In case no message has been sent, MSC-B will take over its role as terminating side for the call initiated via MSC-A.

In case a message has already been sent as indicated in the signaling flow, MSC-B and MSC-A decide both which side will be handling the originating respectively terminating party. In the example of Figure 2, the decision algorithm lead to MSC-A handling the originating side while MSC-B will handle the terminating side.

Now, subject to the implementation as described before MSC-B sends a REL message towards MSC-A with respect to releasing resources for the call initiated by MSC-B towards MSC-A. MSC-B in this implantation acknowledges with an RLC message. Now MSC-B sends an APM message towards MSC-A indicating to proceed with the call initiated by MSC-A. MSC-B may subject to the implementation remove the user busy indication at least with respect to subscriber A, thereby avoiding that subscriber B will be signaled that subscriber B is busy.

Now, the call may proceed by allocation of respective resources, e.g. radio resources, as any other ordinary call. I.e. after speech bearer setup, MSC-B shall send an ACM message to subscriber B and also trigger MSC-A to send ALERTING to subscriber A. MSC-B will send a CONNECT message to subscriber B, in the same time MSC-B return an ANM message to MSC-A to complete the call setup, e.g. by triggering a ringing indication towards the subscribers. I.e. MSC-B thereby assumes the role of the called subscriber. Said CONNECT and ANM messages may be triggered on or after having sent aforementioned message, and may be subject to a delay. By virtue of a delay, subscribers will receive a ring tone for a certain time, thereby providing an audio impression of a normal call. MSC-A will send a CONNECT message to subscriber A upon reception of the ANM message, and the call between A and B is connected.

On the other side, MSC-A shall follow the same logic to detect that the two subscribers are calling each other at the same time and determine the originating side and terminating side of the call. In the above example, MSC-A decides to act as originating side. MSC-A shall wait for the reply to its outgoing 1AM message and subject to the implementation also to a release request message for the incoming 1AM message.

SIP (I) Example

Suppose that the network nodes are core network nodes of a communication network having support for SIP interfaces, in particular SIP-I interfaces, for call handling as shown in figure 3. There a subscriber A having number 123453 indicated as a Mobile Station MS-A issues a setup message towards its associated core network node MSC-A indicating the wish to set-up a call towards subscriber B having number 321654. MSC-A issues via SIP an Invite message indicating that subscriber A wishes to initiate a call towards subscriber B. Said Invite message may comprise a further information element BCC indicating that the MSC-A is supporting the handling of mutual calls.

MSC-B on receipt of the Invite message checks with its associated visitor location register VLR whether subscriber B is marked busy. Since subscriber B has issued a setup message as well, it is marked busy.

Now MSC-B determines whether subscriber A and subscriber B are trying to call each other. Now, MSC-B checks whether an Invite message has been sent already towards MSC-A or not. In case no message has been sent, MSC-B will take over its role as terminating side for the call initiated via MSC-A.

In case a message has already been sent as indicated in the signaling flow, MSC-B and MSC-A decide both which side will be handling the originating respectively terminating party. In the example of Figure 3, the decision algorithm lead to MSC-A handling the originating side while MSC-B will handle the terminating side. Now, subject to the implementation as described before MSC-B sends a BYE message towards MSC-A with respect to releasing resources for the call initiated by MSC-B towards MSC-A. MSC-B in this implantation acknowledges with a 200 OK message.

MSC-B may subject to the implementation remove the user busy indication at least with respect to subscriber A, thereby avoiding that subscriber B will be signaled that subscriber B is busy.

Now MSC-B sends a 183 session progress message towards MSC-A indicating to proceed with the call initiated by MSC-A.

Now, the call may proceed by allocation of respective resources, e.g. radio resources, as any other ordinary call. I.e. after speech bearer setup, MSC-B shall send an 180 Ringing message to subscriber B and also trigger MSC-A to send ALERTING to subscriber A. MSC-B will send a CONNECT message to subscriber B, in the same time MSC-B return a 200 OK message to MSC-A to complete the call setup, e.g. by triggering a ringing indication towards the subscribers. I.e. MSC-B thereby assumes the role of the called subscriber. Said CONNECT and 200 OK messages may be triggered on or after having sent aforementioned message, and may be subject to a delay. By virtue of a delay, subscribers will receive a ring tone for a certain time, thereby providing an audio impression of a normal call. MSC-A will send a CONNECT message to subscriber A upon reception of the 200 OK message, and returns an ACK message towards MSC-B, and the call between A and B is connected.

On the other side, MSC-A shall follow the same logic to detect that the two subscribers are calling each other at the same time and determine the originating side and terminating side of the call. In the above example, MSC-A decides to act as originating side. MSC-A shall wait for the reply to its outgoing Invite message and subject to the implementation also to a release request message for the incoming Invite message.

IMS example

Suppose that the network nodes are core network nodes of a communication network having support for IMS interfaces for call handling as shown in figure 4. There a subscriber A having TEL URI 123453 indicated as a User-A issues an Invite message towards its associated core network node Server-A indicating the wish to set-up a call towards subscriber B having TEL URI 321654. Server-A issues via an IMS protocol an Invite message indicating that subscriber A wishes to initiate a call towards subscriber B. Said Invite message may comprise a further information element BCC indicating that the Server-A is supporting the handling of mutual calls.

Server-B on receipt of the Invite message checks whether subscriber B is marked busy. Since subscriber B has issued a Invite message as well, it is marked busy.

Now Server-B determines whether subscriber A and subscriber B are trying to call each other.

Now, Server-B checks whether an Invite message has been sent already towards Server-A or not. In case no message has been sent, Server-B will take over its role as terminating side for the call initiated via Server-A. In case a message has already been sent as indicated in the signaling flow, Server-B and server-A decide both which side will be handling the originating respectively terminating party.

In the example of Figure 4, the decision algorithm lead to server-A handling the originating side while Server-B will handle the terminating side. Now, subject to the implementation as described before Server-B sends a BYE message towards server-A with respect to releasing resources for the call initiated by Server-B towards server-A. Server-B in this implantation acknowledges with a 200 OK message.

Server-B may subject to the implementation remove the user busy indication at least with respect to subscriber A, thereby avoiding that subscriber B will be signaled that subscriber B is busy. Now Server-B sends a 183 progress message towards Server-A indicating to proceed with the call initiated by Server-A.

Now, the call may proceed by allocation of respective resources as any other ordinary call. I.e. Server-B shall send a 180 Ringing message to subscriber B and also trigger Server-A to send 180 Ringing to subscriber A. Server-B will send a 200 OK message to subscriber B, in the same time Server-B return an 200 OK message to Server-A to complete the call setup, e.g. by triggering a ringing indication towards the subscribers. I.e. Server-B thereby assumes the role of the called subscriber. Said 200 OK messages may be triggered on or after having sent aforementioned message, and may be subject to a delay. By virtue of a delay, subscribers will receive a ring tone for a certain time, thereby providing an audio impression of a normal call. Server-A will send a 200 OK message to subscriber A upon reception of the 200 OK message, and upon receipt of respective ACK messages by Server-A and Server-B the call between A and B is connected.

On the other side, Server-A shall follow the same logic to detect that the two subscribers are calling each other at the same time and determine the originating side and terminating side of the call.

In the above example, Server-A decides to act as originating side. Server-A shall wait for the reply to its outgoing Invite message and subject to the implementation also to a release request message for the incoming Invite message.

PSTN example

Suppose that the network nodes are core network nodes of a communication network having support for PSTN interfaces for call handling as shown in figure 5. There a subscriber A having number 123453 indicated as User-A issues a setup message towards its associated core network node Server-A indicating the wish to set-up a call towards subscriber B having number 321654. Server-A issues via BICC an 1AM message indicating that subscriber A wishes to initiate a call towards subscriber B. Said 1AM message may comprise a further information element BCC indicating that the Server-A is supporting the handling of mutual calls. Server-B on receipt of the 1AM message checks whether subscriber B is marked busy. Since subscriber B has issued a setup message as well, it is marked busy.

Now Server-B determines whether subscriber A and subscriber B are trying to call each other. Now, Server-B checks whether an 1AM message has been sent already towards Server-A or not. In case no message has been sent, Server-B will take over its role as terminating side for the call initiated via Server-A.

In case a message has already been sent as indicated in the signaling flow, Server-B and Server-A decide both which side will be handling the originating respectively terminating party.

In the example of Figure 5, the decision algorithm lead to Server-A handling the originating side while Server-B will handle the terminating side.

Now, subject to the implementation as described before Server-B sends a EL message towards Server-A with respect to releasing resources for the call initiated by Server-B towards Server-A. Server-B in this implantation acknowledges with an RLC message.

Now Server-B sends an APM message towards Server-A indicating to proceed with the call initiated by Server-A.

Server-B may subject to the implementation remove the user busy indication at least with respect to subscriber A, thereby avoiding that subscriber B will be signaled that subscriber B is busy. Now, the call may proceed by allocation of respective resources as any other ordinary call. I.e. Server-B shall send an ACM message to subscriber B and also trigger Server-A to send ALERTING to subscriber A. Server-B will send a CONNECT message to subscriber B, in the same time Server-B returns an ANM message to Server-A to complete the call setup. Said CONNECT and ANM messages may be triggered on or after having sent aforementioned message, and may be subject to a delay. By virtue of a delay, subscribers will receive a ring tone for a certain time, thereby providing an audio impression of a normal call. Server-A will send a CONNECT message to subscriber A upon reception of the ANM message, and the call between A and B is connected.

On the other side, Server-A shall follow the same logic to detect that the two subscribers are calling each other at the same time and determine the originating side and terminating side of the call. In the above example, Server-A decides to act as originating side. Server-A shall wait for the reply to its outgoing 1AM message and subject to the implementation also to a release request message for the incoming 1AM message.

In the following with respect to figure 6 and figure 7 an exemplary determining respectively decision algorithm as well as a respective network node CNN will be described. Note that in the following no specific message types are given but only references allowing for implementing the invention within any kind of suitable wireless or fixed communication network, such as a mobile communication network like GSM, UMTS, LTE, WiMAX, iDEN or the like as well as fixed communication networks like PSTN, ISDN, NGN or the like.

Once started, the network node CNN may check in an optional step 50 whether functionality according to the invention is configured by the operator to be operated. Such a configuration may be stored in memory MEM of the CNN. Suitable memory MEM may encompass RAM, EEPROM, Flash or may be stored on another storage medium such as a hard drive. If the optional functionality is not configured for operation, the decision logic leads to N and normal call processing will be performed as indicated by step 600, i.e. mutual callers may get busy signaling or a call may be redirected towards a mailbox or another subscriber subject to existing mechanisms.

If the optional step 50 indicates that the implemented functionality is configured to be operated, the decision logic leads to Y and the further processing may continue.

At a certain time the network node CNN receives in a step 100 via a respective interface X, a message indicating that a call towards a first party shall be established, whereby a reference allowing for identifying the calling second party is provided, and at a certain time thereafter, it receives in a step 200 via a respective interface RX a message indicating that another call towards the second party shall be established, whereby a reference allowing for identifying the calling first party is provided.

Thereupon, in a step 300 the network node CNN determines whether the first party and the second party are both calling each other.

Now it may be checked within a first decision step 310 whether a message indicating that a call shall be initiated has already been sent towards the first party, and in case no such message has been sent towards the first party, deciding that the first party will be handled as originating party and the second party as terminating party. In this case, the method proceeds via optional step 340 to step 500. In the other case, the method may proceed to step 315. Obviously said step 310 may be optional. Now it may be checked whether it may be decided whether the first party or the second party may decided at all in a step 315. This may be based on the knowledge whether the other network node involved in the call handling is supporting the same logic or not. The knowledge may be received within one of said messages of steps 100 or 200 or it may be preconfigured or it may be previously exchanged. This step 315 may also optional foresee that the decision algorithm is such that there will always one side the terminating side and the other side the originating side. In case the decision algorithm might allow for the rare situation that no clear decision may be rendered, the handling of the mutual calls shall be like there would be no indication of handling logic according to the invention. Also in case the other network node does not support the same logic, the handling of the mutual calls will be as normal call processing as indicated by step 600.

In case an originating and a terminating side may be established the network checks in step 320 whether the network node CNN is acting as terminating or originating side.

In case the network node CNN is acting as an originating node, i.e. the branch "O" is taken, the network node CNN may subject to the implementation await in an optional step 335 any indication by the terminating network node to release the call leg which originated by said terminating network node.

In case the network node CNN is acting as a terminating node, i.e. the branch "T" is taken, the network node CNN may subject to the implementation send via a respective interface TX in an optional step 330 an indication to release the call leg which originated by said terminating network node.

Furthermore, the network node CNN may subject to the implementation remove in an optional step 340 the user busy indication at least with respect to the terminating subscriber, thereby avoiding that the originating subscriber will be signaled that terminating subscriber is busy.

In step 500, the network node proceeds with call handling in a normal manner, i.e. subject to the network type respective resources are allocated and the call is connected.

Now turning again to an example of a decision logic which may be implemented in a determining entity CPU of a network node CNN. Upon receiving an 1AM, the network node checks CNN whether the called party is busy or not.

If the functionality as BCC function is activated, the network node CNN shall check if subscriber B is also calling subscriber A by comparing the calling party number received in the incoming message pertaining to a first call and the called party number received in another incoming message pertaining to another call. In order to avoid mismatch, the Calling Party Number in the incoming messages shall match with the Called Party Number. It may be that an incoming message pertaining to a call doesn't comprise a complete MSISDN, but only the number without Country Code. In this case, only the numbers without Country Code may be used for checking.

If the network node CNN detects the subscriber B is also calling subscriber A at the same time, the network node CNN depending on the own call setup status with respect to an originating call setup may further check whether the remote side has the same functionality according the received message. I.e. if no message has been sent towards the other network node, the detecting network node shall assume its role as a terminating network node. If a message has been sent then the availability of same functionality in the other network node needs to be detected.

If functionality is supported by both network nodes CNN, both network nodes shall use a selection algorithm to choose the originating and terminating sides between A and B.

E.g. a first possibility is that the calling party with the smaller subscriber number will be treated as the terminating side.

However, to avoid unfairness between operators as well as subscribers, one or more digits may be compared in reverse order (from the last digit to the first one). In addition, in order to increase robustness and randomness, the reversed numbers may be sequentially compared digits after digits.

If the calling party numbers do not contain complete MSISDNs, but only numbers without Country Code, only numbers not pertaining to the Country Code may be used for comparison to determine originating and terminating call leg.

In case where the subscriber numbers have different lengths and digits used for determination are similar up to the smallest length, then it may be foreseen that the subscriber number with the smallest length will be treated as terminating side.

Examples of selection algorithm for the Call Party Number: Suppose that the calling party number of User-A is CgPN-A = 1389901, while the calling number of User-B is CgPN-B = 1399901. In this case the last 4 digits are identical but the originating and terminating sides may be decided on basis of the 5th digit. A will be terminating and B will be originating side. Suppose the calling party number of User-A is CgPN-A = 1389901, while the calling party number of User-B is CgPN-B = 389901. Here the digits from CgPN-B are the same as in CgPN-A, but CgPN-B is shorter than CgPN-A, therefore subscriber B is treated as terminating and A as originating side.

If no indication of supported functionality by the other network node is received and a message has been sent, then the network node CNN shall not continue the above selection algorithm and handle the messages using the existing mechanism.

The network node CNN which hosts the terminating call leg shall release an outgoing call leg if it has been already initiated and the related trunk resource subject to the implementation. The network node CNN which hosts the originating leg shall waiting for a response such as a release request subject to the implementation. The network node CNN which acts as terminating side shall send a corresponding message to the other network node CNN and send CONNECT to its hosted user after triggering ringtone for both parties.

If subscriber A and B are in the same network node CNN, the network node CNN knows the subscriber numbers of both subscribers, and the above detection and comparison procedure still apply. In this case, network node CNN internal protocol may be used in a similar way as the external protocol.

A network node, e.g. a core network node CNN, adapted to be involved in handling of call connections, whereby mutual call connection requests are received is shown also in Figure 7. There a network node CNN comprises a receiving entity X for receiving a message indicating that a call towards a first party shall be established, whereby a reference allowing for identifying the calling second party is provided, and for receiving a message indicating that another call towards the second party shall be established, whereby a reference allowing for identifying the calling first party is provided, and a determining entity CPU for determining whether the first party and the second party are both calling each other, and for deciding whether the first party or the second party will be handled as originating party.

The determining entity CPU may be embodied in a microprocessor, a microcontroller, an ASIC (Application-Specific Integrated Circuit)or an FPGA (Field Programmable Gate Array) or any other suitable circuit.

The receiving entity RX may be embodied in a receiver or a receiver part of an I/O unit, e.g. of an Ethernet interface controller or any other suitable interface controller.

Furthermore, the network node CNN may comprise a memory MEM for storing data, e.g. data related to capabilities of other network nodes as well as own capabilities, and may also comprise transmitter unit TX, e.g. included in an I/O unit, for sending respective messages towards other network nodes and / or subscribers and/or network operations.

Furthermore, the determining entity CPU may further be adapted to determine whether a message indicating that a call shall be initiated has already been sent towards the first party, and in case no such message has been sent towards the first party, the determining entity is further adapted to decide that the first party will be handled as originating party and the second party as terminating party.

Additionally, the determining entity CPU may further be adapted to determine whether a message indicating that a call shall be initiated has already been sent towards the first party, and in case such a message has been sent towards the first party, the determining entity is further adapted to decide on basis of a predetermined algorithm whether the first party or the second party will be handled as originating party.

The predetermined algorithm may be based on the references allowing for indentifying the first and second party and/or be based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the references are compared with respect to one or more digits and/or be based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the determining entity CPU is adapted to compare references with respect to one or more digits, whereby the digits pertain to the calling party number respectively the called party number and/or be based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the determining entity CPU is adapted to compare references with respect to one or more digits, whereby digits pertain to the calling party number respectively the called party number, whereby digits pertaining to Country Code and/or Operator and/or Region are not taken into account and/or be based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the determining entity CPU is adapted to compare references with respect to one or more digits in reversed order, whereby digits pertain to the calling party number respectively the called party number and/or be based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the determining entity CPU is adapted to compare references with respect to one or more digits, whereby if those digits which are to be compared do not differ, the decision is based on other parameter such as time of receipt of the respective message indicating that a call towards a party shall be established and/or the overall length of the references allowing for indentifying the first and second party.

Furthermore, the receiving entity RX may be further adapted to receive an indication that another network node involved in handling of said call connections supports handling of calls according one of the previously described methods.

In particular, the receiving entity RX may be further adapted to receive an indication that another network node involved in handling of said call connections supports handling of calls according one of of the previously described methods, whereby the information is contained in an Information Element of an Initial Address Message or an Invite Message or another appropriate message. In case the network node CNN shall handle the originating party the network node's receiving entity X is adapted to receive a further message by said another network node indicating that the calling party is connected, and wherein the network node's determining entity CPU is adapted to await such a received further message before connecting through. In case the network node CNN shall handle the terminating party the network node's transmitting entity TX is adapted to send a further message towards said another Network Node that the calling party is connected. Furthermore, the determining entity CPU may be further adapted to initiate release of an outgoing call leg towards said another network node.

The invention avoids retries due to the fact that deadlocks are avoided and thereby provides for a reduced signaling load. Furthermore the invention enhances user experience as the call connecting time is reduced and the call setup successful rate is increased. In turn of an increased call setup successful rate, revenues for operators may be increased. Also, due to the decision scheme a smooth integration into existing network node environments is ensured, allowing already by a single enabled network node to increase the call successful rate without negatively impacting other not enabled network nodes.

Although the invention has been described with particular reference towards mobile communication networks and particular types thereof, any combination thereof is also encompassed, e.g. while one subscriber may be located in a SIP enabled network another subscriber may be located in a BICC enabled network, or in a IMS enabled network or in a fixed communication network PSTN. Furthermore, even though the invention has been mainly described with respect to network nodes such as core network nodes resembling single entities, the invention may also be embodied in pooled environments such as MSC in pool or in blade environments of server blades providing MSC or like functionality.

The particular combination of elements and features in the above detailed embodiments are exemplary only; the interchanging and substitution of these embodiments with other embodiments disclosed herein are also expressly contemplated. As those skilled in the art will recognize, variations, modifications, and other implementations of what is described herein can occur to those of ordinary skill in the art without departing from the spirit and the scope of the invention as claimed.

Accordingly, the foregoing description is by way of example only and is not intended as limiting. The invention's scope is defined in the following claims and the equivalents thereto. Furthermore, reference signs used in the description and/or claims do not limit the scope of the invention as claimed.

Claims

1. A method for a network node involved in handling of call connections, whereby mutual call connection requests are received, comprising the steps of:

• receiving a message indicating that a call towards a first party shall be established,

whereby a reference allowing for identifying the calling second party is provided,

• receiving a message indicating that another call towards the second party shall be

established, whereby a reference allowing for identifying the calling first party is provided,

• determining whether the first party and the second party are both calling each other

• deciding whether the first party or the second party will be handled as originating party.

2. The method of claim 1, wherein the step of deciding comprises determining whether a

message indicating that a call shall be initiated has already been sent towards the first party, and in case no such message has been sent towards the first party, deciding that the first party will be handled as originating party and the second party as terminating party.

3. The method of claim 1 or 2, wherein the step of deciding comprises determining whether a message indicating that a call shall be initiated has already been sent towards the first party, and in case such a message has been sent towards the first party, deciding on basis of a predetermined algorithm whether the first party or the second party will be handled as originating party.

4. The method of claim 3, wherein the predetermined algorithm is based on the references allowing for indentifying the first and second party.

5. The method of claim 3 or 4, wherein the predetermined algorithm is based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the references are compared with respect to one or more digits.

6. The method of claim 3 or 4 or 5, wherein the predetermined algorithm is based on the

references allowing for indentifying the first and second party, the references being based on digits, whereby the references are compared with respect to one or more digits, whereby the digits pertain to the calling party number respectively the called party number.

7. The method according to one of preceding claims 3 to 6, wherein the predetermined

algorithm is based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the references are compared with respect to one or more digits, whereby digits pertain to the calling party number respectively the called party number, whereby digits pertaining to Country Code and/or Operator and/or Region are not taken into account.

8. The method according to one of preceding claims 3 to 7, wherein the predetermined

algorithm is based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the references are compared with respect to one or more digits in reversed order, whereby digits pertain to the calling party number respectively the called party number.

9. The method according to one of preceding claims 3 to 8, wherein the predetermined

algorithm is based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the references are compared with respect to one or more digits, whereby if those digits which are to be compared do not differ, the decision is based on other parameter such as time of receipt of the respective message indicating that a call towards a party shall be established and/or the overall length of the references allowing for indentifying the first and second party.

10. The method of any preceding claims, further comprising the step of receiving an indication that another network node involved in handling of said call connections supports handling of calls according one of the methods of the preceding claims.

11. The method of any preceding claims, further comprising the step of receiving an indication that another network node involved in handling of said call connections supports handling of calls according one of the methods of the preceding claims, whereby the information is contained in an Information Element of an Initial Address Message or an Invite Message.

12. The method of any preceding claims, wherein in case the network node shall handle the originating party the network node awaits a further message by said another network node indicating that the calling party is connected before connecting through.

13. The method of any preceding claims, wherein in case the network node shall handle the terminating party the network node shall send a further message towards said another Network Node that the calling party is connected.

14. The method of claim 13, further comprising the step of releasing an outgoing call leg towards said another network node.

15. Network Node adapted to be involved in handling of call connections, whereby mutual call connection requests are received, comprising:

• a receiving entity for receiving a message indicating that a call towards a first party shall be established, whereby a reference allowing for identifying the calling second party is provided, and for receiving a message indicating that another call towards the second party shall be established, whereby a reference allowing for identifying the calling first party is provided,

• a determining entity for determining whether the first party and the second party are both calling each other, and for deciding whether the first party or the second party will be handled as originating party.

16. The Network Node according to claim 15, whereby the determining entity is further adapted to determine whether a message indicating that a call shall be initiated has already been sent towards the first party, and in case no such message has been sent towards the first party, the determining entity is further adapted to decide that the first party will be handled as originating party and the second party as terminating party.

17. The Network Node according to claim 15 or 16, wherein the determining entity is further adapted to determine whether a message indicating that a call shall be initiated has already been sent towards the first party, and in case such a message has been sent towards the first party, the determining entity is further adapted to decide on basis of a predetermined algorithm whether the first party or the second party will be handled as originating party.

18. The Network Node according to claim 17, wherein the predetermined algorithm is based on the references allowing for indentifying the first and second party.

19. The Network Node according to claim 17 or 18, wherein the predetermined algorithm is based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the determining entity is adapted to compare the references with respect to one or more digits.

20. The Network Node according to claim 17 or 18 or 19, wherein the predetermined algorithm is based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the determining entity is adapted to compare the references with respect to one or more digits, whereby the digits pertain to the calling party number respectively the called party number.

21. The Network Node according to one of claims 17 to 20, wherein the predetermined

algorithm is based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the determining entity is adapted to compare the references with respect to one or more digits, whereby digits pertain to the calling party number respectively the called party number, whereby digits pertaining to Country Code and/or Operator and/or Region are not taken into account.

22. The Network Node according to one of claims 17 to 21, wherein the predetermined

algorithm is based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the determining entity is adapted to compare the references with respect to one or more digits in reversed order, whereby digits pertain to the calling party number respectively the called party number.

23. The Network Node according to one of claims 17 to 22, wherein the predetermined

algorithm is based on the references allowing for indentifying the first and second party, the references being based on digits, whereby the determining entity is adapted to compare the references with respect to one or more digits, whereby if those digits which are to be compared do not differ, the decision is based on other parameter such as time of receipt of the respective message indicating that a call towards a party shall be established and/or the overall length of the references allowing for indentifying the first and second party.

24. The Network Node according to one of claims 15 to 23, wherein the receiving entity is further adapted to receive an indication that another network node involved in handling of said call connections supports handling of calls according one of the methods of the preceding claims 1 to 14.

25. The Network Node according to one of claims 15 to 24, wherein the receiving entity is further adapted to receive an indication that another network node involved in handling of said call connections supports handling of calls according one of the methods of the preceding claims 1 to 14, whereby the information is contained in an Information Element of an Initial Address Message or an Invite Message.

26. The Network Node according to one of claims 15 to 25, wherein in case the network node shall handle the originating party the network node's receiving entity is adapted to receive a further message by said another network node indicating that the calling party is connected, and wherein the network node's determining entity is adapted to await such a received further message before connecting through.

27. The Network Node according to one of claims 15 to 26, wherein in case the network node shall handle the terminating party the network node's transmitting entity is adapted to send a further message towards said another Network Node that the calling party is connected.

28. The Network Node according to claim 27, wherein the determining entity is further adapted to initiate release of an outgoing call leg towards said another network node.