EA040584B1 - CANCELLED NOTIFICATION METHOD - Google Patents

Description

The invention relates to the field of telecommunications, in particular to methods for informing subscribers about the occurrence of network events generated by subscribers, and can be used by NP (Network Provider) intelligent network operators in MTSS (mobile radio networks) of almost any type - GSM, UMTS, LTE and others .

In accordance with the current state of the art, two levels are common to all types of communication networks: the signaling level is a set of messages and signals that is used by communication network participants (end user devices and network nodes) to perform registration operations, ringing operations, confirmation of readiness, and, possibly, about the features of the supported types of communication (voice, video, coding method), confirmation signals for the beginning or end of a conversation, channel reorganization signals, signals informing the parties (nodes) involved in organizing communication, information about the quality and billing; in digital networks it is also used to transmit information about the services allowed to the user and other information necessary for the operation of the communication network;

media level - the level of organization of the exchange of digitally encoded voice or video information, can allow intermediate transcoding of signals at intermediate nodes, when moving from network to network or when providing additional services.

The indicated logical division into the signal and media levels is valid both for the most modern types of OTT communication networks (Over-the-Top, over the IP-Internet access network), such as Skype, Viber, GoogleTalk, FacebookMessenger, WhatApp, and for classical types of communications, described in the telecommunications standards of ITU-T, ETSI, 3GPP and other institutions.

The telecommunications provider whose network services are used for the OTT service has no control over the latter. This is due to the fact that the user has the opportunity to use the Internet the way he wants. The network operator only carries IP packets from source to destination, he can only know about the packets and their contents. In addition, communication is cheaper for an OTT user, the caller does not pay for the established telephone connection and the lease of the established communication channel.

At the same time, although the TCP / IP protocol is a fairly reliable means of transferring data, nevertheless, standardized protocols for establishing communication (signaling protocols for mobile radio communication systems) provide QoS guaranteed by standards. In this regard, it is interesting that the individual functions of the OTT communication guarantee a more reliable operation than the signaling network of the operator (without taking into account the response time). One such application consequence of OTT communication is the guaranteed delivery to the second end user of the OTT application of the notification of the canceled call by its first subscriber. This is the case when the first subscriber in the OTT application dials the number of the second subscriber and quickly cancels it, based on his own motives. In this case, the OTT communication packet network operates in the normal mode of the TCP/IP protocol and ensures the delivery of TCP/IP packets with the interface of the corresponding OTT application to the end device of the second subscriber, notifying him of a call attempt. In a carrier's signaling network, any operation that a user agent client (UAC) performs is implemented through a series of transactions. Connection dialogs are created by returning non-error responses to requests of certain types. If the call is dropped by the first subscriber, for example, according to the SIP session establishment protocol standard, the connection establishment dialog is terminated with a BYE message. When a BYE message arrives to a participant in a conversation, all sessions associated with that conversation must be destroyed. The UA client of the first, calling user MAY send BYE in both established and early-stage conversations. For example, if the first subscriber canceled the call when establishing a connection with the participation of the forwarding server at the moment when the forwarding server requests the current address of the called user. In this case, the redirect server to the BYE message terminates the connection establishment dialog with the first subscriber, releases the resources, and responds with a 200 OK message to the first subscriber, confirming the release of resources. The connection to the second user is not established, and he is not notified of the abandoned call attempt by the first subscriber.

This property of the signaling protocols of the DAMS, illustrated by the example of the SIP protocol, but not limited to it in the framework of the present invention, seems to the authors to be unfinished from the point of view of both DAMS users and telecom operators. The present invention aims to remedy this shortcoming. Namely, to reliably bring to the called user a notification about a call attempt dropped by the first subscriber at any stage of establishing a connection in the operator's signaling network using any call switching protocols known from the prior art.

Patent US 5859903 01/12/1999 describes a method for notifying a call dropped by the first subscriber in a wired (applied for this invention) telephone network containing the so-called. a service node of a push-button telephone network that connects telephone sets and individual communication lines. The method includes steps in which the service node checks the call from one of the attached communication lines; whether the call is made to the extended connection of subscribers subscribed to the service; whether the called party with enhanced connectivity answered the call. If the answer

- 1 040584 check for these stages is positive, then the receipt of the identifier of the caller (the first subscriber) is checked, stored and sent to the called subscriber.

At the present level of technology, the disadvantages of this method are obvious: a wired, bus connection of the so-called. office lines to the notification device; separate, so-called. extended connection of subscribers subscribed to the service (outputs extension line subscriber 1-n..); impossibility of scaling, performance management, inflexibility of the solution.

At the present level of technology, the application WO 2014/087269 2014.06.12 is known, which describes a method for routing calls from OTT communication networks to OTT networks and networks that are not related to them. According to the method, the caller's operator receives the dialed number of the called party, passes this number to the OTT communication provider, which checks the ability to complete the specified call, after which the result of the check is transmitted to the communication operator, which ensures uninterrupted communication for the calling and called party. Due to this, the authors achieve, as they call it, a seamless connection between subscribers of OTT networks and conventional TTN networks.

This method provides call routing, including a call interrupted by the calling party, due to the fact that packet data transmission in this case ensures the delivery of a message over the operator's signaling network. The disadvantage of such a solution is also obvious, by definition it works only in OTT networks with the corresponding consequences - the need for an OTT application for at least the first subscriber and the impossibility of meeting the QoS standardized in the SPRS. In addition, such a solution does not provide interaction between various OTT networks, such as Viber and Skype, etc.

The technical result of the proposed method for notification of a canceled call is a quick and reliable notification of the called subscriber about the canceled call attempt by the calling subscriber in the SPRS.

The technical result is achieved by a method of notification of a canceled call, according to which the telecommunications provider receives an outgoing call from the calling party, determines the number of the called party, and in the event that the call is canceled by the calling party before informing the called subscriber about this call, the telecommunications provider detects the canceled call, determines that the called subscriber is not informed about the canceled call and generates an informational message about the canceled call to the called subscriber. Moreover, in accordance with the method, the detection of a canceled call is carried out both with the help of a node additionally included in the cellular operator's network, and with the help of a standard network node of the cellular network operator.

The method is illustrated in the drawings:

In FIG. Figures 1 and 2 show a simplified SPRS scheme with options for connecting an additional SCP XDRay node. Fig. 1, 2 do not limit how the SCP XDRay node can be connected to the SPRS architecture, but illustrate two of the main possible connection options within the framework of this invention.

In FIG. 3 is a diagram of the Canceled Call Notification dialog in the SSP-SCP dialog CAP listening mode.

In FIG. Figure 4 shows a diagram of the canceled call notification dialog in the signaling message listening mode using ISUP as an example.

In the figures, the signal network is shown by dashed lines, the data network by solid lines.

This method can be implemented in SPRS of different ITU-T standards, fig. 1 illustrates generalized networks NP A, B, including interacting main nodes - mobile terminals of subscribers MS; switching nodes of SSP services, in different SPRS architectures, its functions are performed by MSC, MME, etc.; a SCP service control node that performs billing functions; an SCP XDRay node providing additional VAS services IN and connected to the operator's core network. Some standardized SPRS nodes - base station system BSS, gateway nodes GW, etc. for the purpose of simplification in FIG. 1 are not shown. Also, to simplify FIG. 1, it is assumed that the registers VLR, HLR, HSS, as well as SMSC are part of the SSP.

Within the framework of the proposed method, but without limiting the scope of its legal protection to the hardware and software part of the VDO node, the PAK SCP XDRay is presented. This method can be implemented by various HSS architectures, which are either a separate SPRS node or a part of an existing standardized network node. SCP XDRay - a complex for notification of subscriber behavior events in cellular networks developed by the authors - application WO No. 2013107454. The complex can be passively connected to the operator's network and can be configured to capture any dialogues of the operator's core network, the software logic of its operation, which is know-how authors, is optimized for instant response to captured events and is configured by the time of formation and transmission of notification messages to the network and the possibility of their reception by subscribers or the operator. Subscriber parameters are extracted from intercepted messages and compared with the subscriber's profile data using a special algorithm of the software package to generate a notification method. In different architectures, SCP XDRay can listen to network communications by communicating with a gateway node, a switching node as in FIG. 1 SCP or by connecting to the physical network of the PCS through the generalized gateway of FIG. 2.

The hardware-software architecture of SCP XDRray is optimized for instant response to the events of the operator's signal network in the capture-storage-notification linkage, and the HSS provides such linkage in various combinations.

Fig. 3 illustrates the implementation of SCP XDRay using CAMEL technology. In this variant, SCP XDRay passively listens to the CAP dialogue between SSP and SCP. In accordance with the basic call state model (BCSM) paradigm, the call processing in the SSP moves from one call state to another (PIC - Points in Call). Access to IN services for specific PICs is defined in the so-called. trigger points detection point DP. Subscription to the dropped call notification (CAMEL Subscription Information, CSI) service can be made in the subscriber's HLR profile or directly on the SSP (Network Service CAMEL Subscription Information, N-CSI). An outgoing call is processed at the SSP (Vistor MSC) in which the subscriber is currently registered. The MSC's VLR already contains a copy of the subscriber's profile, and thus a subscription record for the dropped call notification service. In another embodiment, the dropped call notification may be a predefined CPSS functionality and be provided without a subscription. Subscriber A initiates an outgoing call after an SSPMS signaling exchange involving a service request, in this case an outgoing call, to simplify the diagram of FIG. this dialog is placed in the 1 Setup message. An initial DP call state is generated, indicating that an invocation of intelligent services has been detected, and the SSP-SCC conversation begins. The SSP initiates a 2 InitialDP(A, B) request to the SGP requesting an indication of call processing. After parsing, the SCP responds with a 3 RRB\ACH..\CONt RequestReportBCSM + Continue + ApplyCharging message with billing permission. At this time, the call sequentially transitions to the PIC O_Null & Authorize OrigmationAttempt states, which includes checking subscriptions, call denials, etc.; Collect_info, Analyze_Information - parsing subscriber's subscription data; parsing the called number; Routing & Alerting, which includes a call to subscriber B. If the called subscriber answers, the call is transferred and the state is DP O_Answer, or other DPs, depending on network events - subscriber B is busy, does not answer, etc., in accordance with the recommendations of ITU-T Q.1214 . SCP XDRay monitors all dialogue in mirror traffic in passive mode (Fig. 1). If, at the moment of the dialogue SSP A - SCP A, subscriber A cancels the call by pressing the hang up button, MS A sends a 4 REL message to the network. The SSP generates an O_Abandon event indicating that the caller releases the call before the call reaches the active phase in which the called party's SSP B is signaled an incoming call, Routing & Alerting", for example, and sends an appropriate 5 O_Abandon message to SCP. This event can occur during BCSM creation, is in PIC or Null, or during user interaction at the start of a call (BCSM is in DP information collected), and does not contain a reason code in the failure notification. Those. the message can be transmitted to the SSP SCP dialogue at any stage of the signaling exchange before CAP message N (in the figure, the CAP message N-1 and CAP message N messages are not numbered because in this case the dialogue is interrupted, they are not transmitted). The SSP releases the connection establishment resources and sends an acknowledgment 6 to the RLC. SCP XDRay intercepts the OAbandon message and starts notification procedure for subscriber B. The SCP XDRay HAC sets up a signaling dialog 7-14 to notify the called subscriber C. Immediately after receiving the confirmation of SSP B, the full software algorithm generates a release message 8 REL (A, B). Subscriber B is notified of a call attempt by subscriber A. Additionally, SCP XDRay can send an SMS notification to subscriber B 15-16.

Such an implementation of the method is preferred and, without limiting the scope of legal protection, is the main mode of operation of SCP XDRay. SCP XDRay's passive mode is limited to listening for signaling, and the SSP is exempt from drop notification switching. It provides the principles of component construction of the IN network, separates the functions of switching and call service control. The implementation excludes the signaling exchange between the SSP switching node and the SCP XDRay node providing VAS services, which is certainly preferable from the point of view of SPRS service.

Fig. 4 illustrates an ISUP signaling exchange diagram in which SCP XDRay passively listens for signaling traffic using the ISUP example and notifies callee B. In this implementation, SCP XDRay passively listens for signaling traffic (ISUP) in the operator's core network outside of the SSP-SCP CAP conversation.

Subscriber A initiates an outgoing ISDN call, MS A sends a 1 Setup message to outgoing SSP A. Upon receiving a connection setup request from the calling subscriber, outgoing SSP A parses the route information and generates an initial address IAM message. The IAM message conveys address information, also information related to connection establishment, compatibility parameters, etc. SCP XDRay intercepts the 1 Setup signaling message to initiate connection establishment procedures, marks the subscriber profile A with the outgoing call establishment procedure flag, this is possible due to the preliminary accumulation of subscriber profiles on SCP XDRay. If subscriber A cancels the outgoing call and resets it (hangs up), MS A sends message 2 REL to the network - notification of the release of the channel used in the connection, the message informs SSP A of the need to release the resources involved in establishing the connection . SSP A by ISUP cause codes, in this case MS A's 16-normal call termination on request, resets the trunk elements and sends an acknowledgment 3 to the RLC. In this case, SSP A does not guarantee that the IAM will be sent in the direction of the called subscriber B to the incoming SSP C or transit SSP, and therefore does not guarantee that subscriber B is informed of the call attempt. SCP XDRay intercepts the 2 REL message, its software algorithm associates the received disconnect message from MS A with the active sign of the subscriber profile - an outgoing connection is established. On the basis of the REL ISUP cause codes =16, as well as on the condition that the initial IAM message does not appear on the operator’s network, and / or the request for additional INR information, the response to it from the outgoing SSP A - INF, and / or the switch confirmation - the address is sufficient ACM, software algorithm SCP XDRay determines that Subscriber B is not aware of the dropped call. And starts the notification procedure for subscriber B. The SCP XDRay PAC sets up a signaling dialog 4-11 to notify the called subscriber C. Immediately after receiving the confirmation of the SSP B address, the complete software algorithm generates a release message 8 REL (A, B). Subscriber B is notified of a call attempt by subscriber A. Additionally, SCP XDRay can send an SMS notification to subscriber B 12-13.

Such an implementation of the method may be relevant if it is impossible to listen to the CAP dialogue. The implementation also excludes the signaling exchange between the switching node SSP and the node VAS services, which is certainly preferable from the point of view of SPRS service. The disadvantage and price for such separation of functions, in this way of listening to signal traffic, is the increased load on SCP XDRay in terms of monitoring all outgoing calls and controlling their completion. Even taking into account that the SCP XDRay software algorithm is optimized for instantaneous writing-reading of the outgoing connection establishment indicator of the subscriber profile, the load on the server is estimated to be significant.

As is clear to a specialist, using the ISUP protocol as an example, this method can be used not only in SPRS networks, but also in PSTN networks of the public switched telephone network.

The method can be implemented in a semi-active mode (less preferred). In this case, the signaling exchange between SCP XDRay and SSP or/and SCP A is enabled. And after interception and processing of the O_Abandon message, SCP XDRay exchanges data with SSP or/and SCP A to switch the notification of the called subscriber. In this case, the initiation and termination of the connection (messages 7-16 of Fig. 2) to notify the called subscriber is performed on SSP A. The essence of the method also assumes notification of a dropped call and without the SCP XDRay node. In this case, the signaling exchange 7-16 of FIG. 2 is made between SSP A and SSP B. A SCP XDRay is either not present in the network architecture or performs other functions (provides other services). In this case, the generalized caller release handling and callee notification logic is executed on SSP A and/or SCP A.

The capabilities of the SCP XDRay HAC provide an implementation of a method in which messages from the operator's radio network, for example, over the DTAP GSM (Direct Transfer Application Part) protocol, and / or lu interface with circuit switching CS, packet switching PS for LTE networks. In this case, the SCP XDRay node receives mirrored traffic from the operator's radio network on the MS-MSC (GSM), UTRAN-CN (LTE) section. This implementation option is preferable in terms of the speed of the method, in which message delays on the switch and in the operator's core network as a whole do not affect the notification rate. In this case, the general logic of the method is saved taking into account the formats of the protocols (interfaces) used in the SPRS radio network.

The implementations of the work described above illustrate some of the many implementations of the notification method, it is obvious to a specialist that the essence of the method is implemented not only by the CAP / ISUP intelligent call control protocols, but also by the SIP session establishment protocol, for this, the SIP server is included in the SCP XDRay PAC. The logic for executing the method over the SIP protocol is similar to the one above, taking into account the SIP API standards, and generally consists in generating an SCP XDRay notification before the end of the SIP session establishment when it is interrupted by the caller. The paradigm of the proposed notification method fits well with other call switching methods known from the prior art.

Notifications to the called subscriber can be formed as SMS, USSD, PUSH messages, in any other formats known from the current level of technology.

This method has been implemented and is being operated by the applicant in the DSS of a well-known operator based on the SCP XDRay complex and has shown the effectiveness of reliable notification of subscribers about a canceled call in accordance with standardized QoS requirements.

Claims (3)

1. The canceled call notification method, according to which the telecommunications provider receives the outgoing call of the calling party, determines the number of the called party, characterized in that if the call is canceled by the calling party before informing the called party, - 4 040584 about this call, the telecommunications provider detects the canceled call, determines that the called subscriber is not informed about the canceled call and generates an information message about the canceled call to the called subscriber. 2. The notification method according to claim 1, characterized in that the detection of the canceled call is carried out using a node additionally included in the network of the cellular operator. 3. The notification method according to claim 1, characterized in that the detection of the canceled call is carried out using a standard network node of the cellular network operator.