Browse Prior Art Database

CAMEL based Call Transfer for IN-VPN in GSM or UMTS Networks (CCT) Disclosure Number: IPCOM000018400D
Original Publication Date: 2002-Jun-01
Included in the Prior Art Database: 2003-Jul-23
Document File: 2 page(s) / 518K

Publishing Venue


Related People

Georg Reininghaus: AUTHOR [+2]


In order to enable a GSM or UMTS subscriber (B- Party) to use her mobile phone to connect a calling party (A-Party) to another party (C-Party) there is a core network solution called ETC (Explicit Call transfer) that is specified by the ETSI (European Technical Standards Institute) standard. However this solution does not work together with IN (Intelli- gent Network) services.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 51% of the total text.

CAMEL based Call Transfer forIN-VPN in GSM or UMTS Net-works (CCT)

Information / Kommunikation

Idee: Georg Reininghaus, A-Wien;

Andreas Zöchling, A-Wien

In order to enable a GSM or UMTS subscriber (B-Party) to use her mobile phone to connect a callingparty (A-Party) to another party (C-Party) there is acore network  solution  called  ETC  (Explicit  Calltransfer)  that  is  specified  by  the  ETSI (EuropeanTechnical Standards  Institute)  standard.  Howeverthis solution does not work together with IN (Intelli-gent Network) services.

A  CAMEL  (Customised  Applications  for Mobilenetwork Enhanced  Logic)  based  Call  Transfer  forIN-VPN (IN-Virtual Private Network) is proposed inorder to establish a connection between A- and C-Party. Prior to transfer a connection shall have beenestablished on the call between A and B. Using thesupplementary service “Call Hold” the served sub-scriber (B-Party) sets up a second connection to theC-Party to ensure  that the C-Party is reachable. Thecall (transfer) between A and C is established whenthe connections B to C and A to B are released by theB-party.

Following preconditions have to be satisfied beforeinvoking CCT (Camel based Call Transfer):

•   The VPN service has  to  check  the  chargingscenario and call permissions after transfer. If soVPN has to provide corresponding charging rec-ords, otherwise the transfer request shall be re-jected by VPN.

•   The served subscriber (B-party) has to be pro-vided with CSI information for VPN-call as wellas USSD.

•   The call A to B shall be in the state [active; held]and the call B to C in the state [active; idle].

•   No other originating or terminating call exists atthe access of the B-party. Forwarded calls arenot relevant.

The served subscriber may initiate CCT as follows:

1.     The Mobile Station (MS) activates the service bysending a USSD  request  towards  the  networkindicating  the  Call  Transfer  request. The net-work does not change the call state of the con-nection A- to B-Party or B- to C-Party when re-ceiving the request.

2.     The network normally accepts the USSD requestand forwards it  to  the  IN-VPN  service  (viaMSC/VLR, HLR and CSE).

3.     On receipt the  IN-VPN  service  provides  fol-lowing checks:

-     The  permission  of  the B-party is checkedbased  on  the  received  MSISDN (MobileSubscriber  ISDN  number)  against  black-/whitelists.

-     The call scenario is checked (one call active,one held).

-     The  charging  scenarios  are  checked. Nor-mally B- and C-party must be VPN mem-bers.

4.     If all checks passed,  CCT  is  activated  and  aconfirmation  with  USSD  response  is  sent  to-wards the B-Party MS. Otherwise the request isrejected  with a USSD response. Note that thestate of the calls is not changed at that time.

5.     To invoke CCT the served subscriber requestsrelease of her calls to A and C.

-     On receipt the network terminates the call to


-     Subsequently the...