Patent Application
20100184418
The present invention relates to a method for controlling explicit call transfer in a telecommunications network.
Explicit Call Transfer (ECT) supplementary service enables a mobile subscriber (subscriber A) who has two calls, each of which can be an incoming or an outgoing call, to connect the two other subscribers (subscribers B and C) to each other and release his connection with the Mobile Switching Center (MSC). The ECT supplementary service for the GSM network and for the third generation mobile network (3G network) is specified by 3GPP in the following technical specifications (TS): 22.091 version 6.0.0, 23.091 version 6.0.0 and 24.091 version 6.0.0.
The Customized Applications for Mobile network Enhanced Logic (CAMEL) feature is a GSM Phase 2+ and UMTS network feature providing the mechanisms to support operator-specific services that are not covered by standardized GSM or UMTS services, even while a mobile subscriber is roaming outside the Home PLMN (HPLMN). When a call is subjected to the control by a Service Control Point (SCP) via e.g. the CAMEL Application Part (CAP) protocol, subscriber A is basically the “served subscriber” that has an IN category (O-CSI, D-CSI, T-CSI, VT-CSI . . . ) due to which the SCP is linked in the traffic chain for controlling the call and/or being notified of events happening during the call. When the SCP is invoked due to an O-CSI, D-CSI, N-CSI or VT-CSI with CAP v3 or CAP v4, the SCP may use a CAP Continue With Argument (CWA) or CAP Connect (CON) operation to instruct the MSC to allow the served subscriber to invoke ECT during the call or to instruct the MSC to disallow the served subscriber to invoke ECT during the call.
A problem may occur when the SCP instructs the MSC to allow the served subscriber to invoke ECT during the call. In such case, the served subscriber may invoke ECT during the call, possibly resulting in unexpected service behaviour, such as incorrect or unexpected announcements played to the parties of the call, incorrect charging to be applied for the calls or incoming calls not being delivered to the served subscriber.
A goal of the present invention is to provide methods, devices and computer programs that overcome aforementioned problem and improve the control of explicit call transfer in a telecommunications network.
This goal is achieved by providing a method for controlling an explicit call transfer during a call in a telecommunications network comprising a switching node and an intelligent network, the intelligent network comprising a service control entity and a service switching entity. The service switching entity detects that explicit call transfer is invoked. It will then send a report to the service control entity indicating that explicit call transfer took place for the call. The service switching entity will then receive an instruction from the service control entity indicating how to continue the call, and it will execute that instruction. The service switching entity makes the service control entity aware of an ECT invocation by the served subscriber so that the service control entity can take appropriate actions.
In a further aspect, the invention relates to a method for controlling an explicit call transfer during a call in a telecommunications network comprising a switching node and an intelligent network, the intelligent network comprising a service control entity and a service switching entity. The service control entity receives a report from the service switching entity indicating that explicit call transfer took place for the call. It will then process the report and send an instruction to the service switching entity depending on the result of the processing of the report.
The invention further relates to a method for controlling an explicit call transfer during a call in a telecommunications network comprising a switching node and an intelligent network, the intelligent network comprising a service control entity and a service switching entity, wherein the service switching entity detects that explicit call transfer is invoked. It will then send a report to the service control entity indicating that explicit call transfer took place for the call. The service control entity receives the report from the service switching entity indicating that explicit call transfer took place for the call and the service control entity will then process the report. Next, the service control entity sends an instruction back to the service switching entity depending on the result of the processing of the report. The service switching entity receives the instruction from the service control entity indicating how to continue the call and then the service switching entity executes the instruction.
The invention also relates to a service switching entity for an intelligent network which provides intelligent network services to users of a telecommunications network. The intelligent network comprises a service control entity connectable to the service switching entity. The service switching entity is connectable to a switching node in the telecommunications network, and comprises a processing unit, an input unit connected to the processing unit and an output unit connected to the processing unit, wherein the input unit is arranged to receive messages from the switching node and to receive instructions from the service control entity. The processing unit is arranged to:
The invention further relates to a service control entity for an intelligent network which provides intelligent network services to users of a telecommunications network where the service control entity is connectable to a service switching entity in the intelligent network, and comprises a processing unit, an input unit connected to the processing unit and an output unit connected to the processing unit. The input unit is arranged to receive messages from the service switching entity, and the processing unit is arranged to:
Finally, the invention relates to a computer program product comprising computer executable code, which when loaded on a computer system, allows the computer system to execute the method as described above.
The present invention will be discussed in more detail below, using a number of exemplary embodiments, with reference to the attached drawings, in which:
The present invention may be applied in communication networks, e.g. a mobile telecommunication network. The relevant parts of such a telecommunication network for the present invention are shown schematically in
The MSC 18, SSF 17 and the SCP 16 may be implemented as network units 201, the structure of which is shown in simplified form in
The method described below in accordance with a number of embodiments of the present invention entails that the SSF 17 uses a state model method well known in present day telecommunication networks called Basic Call State Model (BCSM).
A BCSM can be described using the following elements:
Points in Call
Detection points
Transitions
Events
Calls progress through a series of states that correspond to Points in Call (PiCs). Each state change represents a transition that is precipitated by one or more events. Those PiCs where a transfer of control can occur between the SSF 17 and the SCP 16 have an associated detection point (DP). A DP may also relate to an event that, when it occurs, does not result in a state transition. This situation is sometimes referred to as ‘transition to the same state’. DP processing allows the transition to be seen by the SCF 19 through an event reporting mechanism. First, the SCF 19 performs a so-called Request Report BCSM operation. This operation is used to request the SSF 17 to monitor for a call-related event (e.g., BCSM events such as busy or no-answer), then send a notification back to the SCF 17 when the event is detected. Next, the SSF 17 performs a so-called Event Report BCSM operation which is used to notify the SCF 19 of a call related event, provided that the reporting of the occurrence of this event was previously requested by the SCF 19 in the Request Report BCSM operation. The monitoring of more than one event can be requested with a single Request Report BCSM operation. Each requested event is reported in a separate Event Report BCSM operation.
An instance of a BCSM is invoked when the MSC 18 has deduced that a call shall be subject to IN control. The type of BCSM that is instantiated depends on the call case. For a Mobile Originating (MO) call for which a CAMEL service shall be invoked, an O-BCSM (Originating BCSM) is instantiated, as is schematically shown in
Two types of DPs can be defined:
When a DP is ‘armed’, the SSF may send a notification to the SCP when an event related to that DP occurs.
Detection points, when armed and met, cause event reports to be sent to the SCP 16. An event report can be a notification or a request. A notification informs the SCP 16 of an event and a request specifically requests assistance from the SCP 16. A request implies, in addition to the aforementioned notification, a transfer of control to the SCP 16.
Prior to invoking explicit call transfer, see arrow 45, the connection of the call between subscriber A and subscriber B must have been established and subscriber A must have put subscriber B on hold. On the call between subscriber A and subscriber C, either the connection must have been established prior to transfer, or, transfer can occur while subscriber C is being alerted of the call. When the execution of ECT supplementary service is complete, both subscribers B and C are notified that ECT has been invoked, with an ISDN User Part (ISUP) or Bearer Independent Call Control (BICC) Call Progress (CPG) message in the case that the call to the subscriber is in alerting phase, or with an ISUP/BICC Facility (FAC) message in the case that the call to the subscriber is in active state, see arrows 46, 47, 48, 49, 50, 51. When an MSC and its associated SSF are located in the same node, said ISUP or BICC messages may have the form of a vendor-specific internal ISUP/BICC equivalent message. Once the MSC-A 41′ has sent the FAC or CPG messages, it sends a DISCONNECT message to the mobile terminal 41, see arrow 52, which in return sends a RELEASE message back, see arrow 53. Finally, the MSC-A 41′ sends a RELEASE COMPLETE message to the mobile terminal 41, see arrow 54. Note that for simplicity reasons, the MSC-A 41′ and SSF are shown once only (the call leg A-B and the call leg A-C have their own MSC process instance, SSF process instance and SCF instance). The term ‘leg’ or ‘call leg’ is common terminology in circuit switched telecommunication; it is used, amongst others, within the description of MSC or SSF; it refers to the logical connection to or from a party in a call.
The CPG or FAC messages mentioned above may contain also the number of the other subscriber the call is connected to from that moment on (that is B-number for subscriber C and C-number for subscriber B). This number is carried in a parameter called “Call Transfer number”; it is referred in the remainder of the description. This parameter is defined in ITU-T recommendation Q.732.7 (1996), “Stage 3 description for call offering supplementary services using Signalling System No. 7: Explicit Call Transfer”.
The invention aims at making SCP 504 aware of an ECT invocation by the served subscriber so that the SCP 504 can take appropriate actions.
Similar to the enhancement to the O-BCSM, as shown in
Basically, the SCP 504 will take into account the ECT successful invocation and the new connected subscriber. By receiving the event report (ERB), the SCP 504 obtains information from the network about successful ECT invocation by the served subscriber, and the new connected subscriber. This information can be used to apply service logic taking into account the new connected subscriber and act appropriately, considering that a subscriber that was in the call is no longer connected in the call. The embodiment described above can be implemented as follows:
a) adding a new EDP to the Basic Call State Models (BCSM) for CAMEL: “call transfer invoked” to indicate that ECT has been invoked on the call leg encountering the DP;
b) adding a BCSM event in the Request Report BCSM operation and in the Event Report BCSM operation to arm and report (respectively) the new EDP at point a);
c) adding a new information field in the ERB operation; this new information field will contain said call transfer number, as well as an indication of the phase of the call in which the call transfer took place.
The following enhancements to the CAP protocol may be introduced to provide the SCP 504 with the capabilities described above:
a) add a new Event Type O_ECT_Occurred and T_ECT_Occurred in the Event Report BCSM operation to specify that ECT was invoked. The event for which the Event Report BCSM operation is sent from SSF to SCP is indicated in the parameter ‘Event Type BCSM’.
The Event Report BCSM operation may contain the parameter ‘Event Specific Information BCSM’. If the Event Type BCSM IE contains either “O_ECT_Occurred” or “T_ECT_Occurred”, then the Event Specific Information BCSM parameter contains the following information elements:
b) add a new event type “O_ECT_Occurred” and “T_ECT_Occurred” in the Request Report BCSM operation to arm the new EDPs mentioned above.
The following table shows a possible mapping between ISUP FAC/CPG parameters and corresponding CAP ERB parameters in DP specific info. ISUP parameters are taken from ITU-T Recommendation Q.763 (1999). Please note that in the case of ECT invocation, the Notification Indicator Parameter contained in Generic Notification Indicator (this parameter is present both in ISUP FAC and CPG) can be received by the SSF 44 with values “call transfer, alerting” or “call transfer, active”.
A possible ASN.1 coding for the Call Transfer Phase is the following:
Coding for Call Transfer Number can be exactly the same as for ITU-T Recommendation Q.763 (1999) and is depicted below.
c) Modify the Basic call state model to include the two new DPs that will be hit when the basic call in the SSF 44 receives a FAC/CPG message indicating that ECT was invoked. If the DP was previously armed in the BCSM instance for this call, the SSF 44 will send an ERB to the SCF 506 indicating “O_ECT_Occurred” or “T_ECT_Occurred” depending upon whether the SSF 44 was invoked in an originating or in a terminating call respectively. The SSF 44 will populate DP specific info with the Call Transfer number received in the ISUP FAC/CPG message as well as with the indication of the phase of the call in which the ECT took place.
In
In
According to an embodiment, the service switching entity is the SSF 44 of an IN as described above. The SSF 44 will create an instance of a BCSM. The BCSM comprises an event detection point indicating that explicit call transfer was invoked. See also
In an embodiment, the service control entity is the SCP 16 of the IN as described above. The SCP 16 creates an instance of a BCSM. Then it sends a request to said SSF 17 for a report from the SSF 17 when an event related to the event detection point has occurred. Next, the SCP 16 receives an event report from the SSF 17 when the event related to the event detection point has occurred. The event report comprises a call transfer number and an indication of the phase of the call, e.g. during an active call or during an alerting phase of the call, in which the event took place.
The invention gives the SCP 506 the ability not only to forbid invocation of ECT service in a particular call, but also to allow invocation of ECT and to know which subscribers are in the call and who has left, when ECT was invoked. Based on this information, the SCF can apply appropriate service logic taking into account the new connected subscriber.
In an embodiment, the SCP 506 is arranged not to send an “end of call balance notification” Unstructured Supplementary Service Data (USSD) message to the subscriber that invoked the explicit call transfer service, if she is no longer in the call. Without the invention, the served subscriber would receive the USSD message, whilst she might by then already be engaged in another call or may otherwise not expect the USSD message.
According to a further embodiment, the SCP is arranged to correctly handle ECT invoked by hunt group agents. When a hunt group agent or call distribution group agent transfers an incoming or outgoing call to another destination, the service logic will be notified that the agent is now available again for receiving calls. Without the invention, the agent would remain marked as “busy”, which has the effect that she can't receive incoming calls whilst she is in fact available.
When the SCP 506 is informed that the served subscriber has invoked ECT, the SCF will know that the served subscriber no longer occupies a radio channel over the radio access network. In an embodiment, the SCP 506 is arranged to adapt (reduce) the rate of the call when the served subscriber is no longer in the call.
In a further embodiment, the SCP 506 is arranged to decide not to play announcements or tones towards the served subscriber after ECT invocation. Without the invention, these announcements or tones would be heard by the subscriber C or the subscriber B instead of by the served subscriber.
In an embodiment, the SCP 506 is arranged to forbid ECT depending on the result of the processing of the report of the SSF 44. The SCP 506 may decide to forbid ECT depending on one or more criteria. More specifically, criteria that can only be checked during the call, such as, for example, the call transfer number. When the subscriber establishes a call, the SCP 506 instructs the SSF 44 to allow ECT to be invoked by the served subscriber. When the served subscriber wants to invoke ECT, the service may, however, decide that this particular combination of calls does not qualify for ECT and to release the call. For example, an enterprise may decide that ECT is allowed only between connected parties that also belong to this enterprise.
In yet another embodiment, the SCP 506 is arranged to allow the call for which ECT was invoked to continue. The SCP 506 may adapt its service logic processing, considering the new call connection that has become effective due to the explicit call transfer.
On top of these new possibilities the operators will be allowed to build up new Value Added Services and to have a better interaction between these services and ECT.
The present invention has been explained above with reference to a number of exemplary embodiments. As will be apparent to the person skilled in the art, various modifications and amendments can be made without departing from the scope of the present invention, as defined in the appended claims. The invention could also be implemented in wireline networks, e.g. ISDN.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/NL2007/050288 | 6/15/2007 | WO | 00 | 1/11/2010 |
