GB2452020A

GB2452020A - Communication establishment methodand related communication devices

Info

Publication number: GB2452020A
Application number: GB0714104A
Authority: GB
Inventors: Frederick Fok
Original assignee: NEC Technologies UK Ltd
Current assignee: NEC Technologies UK Ltd
Priority date: 2007-07-20
Filing date: 2007-07-20
Publication date: 2009-02-25
Also published as: GB0714104D0

Abstract

The present invention provides for a method of establishing a communication session between a first communications device 10 and a remote party 24 and including the step of initiating the communications session establishment in the first mobile radio communications device 10 by way of near field communication (NFC) 16 with a second mobile radio communications device 18 already in communication with the remote party 24. In one embodiment a voice call session is transferred by way of a NFC session to device 10 which replaces device 18 in the call session. In another embodiment, NFC between device 10 and device 18 allows device 10 to join a conference call which device 18 is already engaged in.

Description

COMMUNICATION ESTABLISHMENT METHOD

AND RELATED COMMUNICATION DEVICES

The present invention relates to a communication establishment method and related communication devices.

Communication session establishment in a manner seeking to preserve a communication session and/or transfer the same has been the subject of discussion within 3GPP-related proposals, for example. there are active discussions on Voice Call Continuity within 3GPP Standardization and related works refer to Technical Specification 24.206 Voice Call Continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS)". The VCC technology is based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) and the protocols of the 3GPP Circuit-Switched (CS) domain (CAP, MAP, ISUP, BICC and the NAS call control protocol for the CS access).

Such previously proposed VCC enables users to move between the CS domain and IP Connectivity Access Networks such as Wireless Local Area Network (WLAN) with home IM CN Subsystem functionality.

Also, while addressing methods are employed for connecting to remote parties, they are becoming increasingly complicated and multiple forms now exist, for example, telephone URI, SIP URI, mail URI. etc). Also, a single user can have several Public User Identities which can be shared by several devices owned by that user. Therefore when a transfer of a call is performed from one mobile device to another, it is necessary for the user to have knowledge of the remote party number. In addition, in existing call transfer methods a call can he transferred to a remote device as a callee, but the ability for the remote device to receive the call as a caller is not yet possible. Moreover, when a call transfer is performed the call may not be available or may not be appropriate for a call transfer.

Furthermore the current specification of VCC is solely applicable for a domain transfer for a telecommunjcatjoji mobile device.

The present invention seeks to provide for a communication established method and related communication devices having advantages over known such methods and devices.

According to a first aspect of the present invention there is provided a method of establishing a conimunicafion session between a second mobile radio communications device and a remote party and including the step of initiating the communications session establishment in the second mobile radio communications device by way of near field communication with a first mobile radio communications device already in communication with the said remote party.

The invention advantageously serves telecommunication call session transfer from one device to another. The transfer of a call requires the knowledge of the remote telecommunication device!s addressing number, its capabilities and preferred access domain (e.g. CS Domain, IMS domain,.. .)and these can accurately and efficiently be provided by the NFC session. As will be appreciated further from the following, multiparty capabilities should also he allowed so that the remote user can join the conference without knowing the confCrence ID (e.g. by means of a 1JRI).

By using NFC technology, the invention also advantageously enables safe and easy wireless communication setup (e.g. Wifi, Bluetooth,

.). Therefore a user can attain authenticated access to an access point by simply touching a remote NFC compliant device.</p>..DTD: <p>Preferably, the communications session comprises a call session. In particular.

the establishment of the communications session within the second mobile radio communications device can include a domain transfer.

In particular, the establishment of the communications session within the second mobile radio communications device can comprise transfer of the session from the first device to the second device.

In this manner, the second device can he arranged to be the caller or the callee, for the communication session.

As an alternative, or in addition, the communication session can comprise a multiparty session to which the second mobile radio communication device is to be introduced by way of the first mobile radio communications device.

The first communication device can then be arranged to transfer its participation in a conference call to the second mobile radio communications device.

As a particular feature, the NFC can be employed to establish a peer-to-peer communication channel between the first and second devices or, alternatively, the NFC can be arranged to set up a secure wireless communication session such as by way of a WiFi or Bluetooth session as appropriate.

In particular, the method can employ NFC for negotiating communication device parameters.

Advantageously, such negotiation is conducted prior to the establishment of the communication session.

In particular, the call transferred can comprise any one or more of a voice, video or data communication exchange. Also, if a plurality of such exchanges are available or in progress, the transfer can he arranged in relation to only one of such plurality of exchanges.

According to another aspect of the present invention there is provided a mobile radio communications device arranged for communicating via a communication Session with a remote party by way of a mobile radio communications network, the mobile radio communications device having near field communications capability and thereby being arranged to have the communication session initiated by way of near field communications with a Further mobile radio communications device already in communication with the remote party.

As above, the establishment of the communications Session within the second mobile radio communications device can comprise transfer of the session from the first device to the second device.

In this manner, the said mobile radio communication device can be arranged to be the caller or the callee, for the communication Session.

As an alternative, or in addition, the communication session can comprise a multiparty Session to which the said mobile radio communication device is to be introduced by way of the said further mobile radio communications device.

The said further communication device can then be arranged to transfer its participation in a conference call to the said mobile radio communications device.

As a particular feature, mobile radio communicatjoi can he employed to establish a peer-to-peer communication channel between the said further and the said second device or, alternatively, the near field communication can be arranged to set up a secure wireless communication session such as by way of a WiFi or Bluetooth session as appropriate.

In particular, the said device is arranged to employ near field communication for negotiating comm unicati on device parameters.

Again, the call transferred can comprise any one or more of a voice, video or data communication exchange. Also, a plurality of such exchanges are available, the transfer can he arranged in relation to only one of such plurality of exchanges.

According to yet a further aspect of the present invention there is provided a mobile radio communications device arranged for communication via a communication session with a remote party and by way of a mobile radio communications network, the mobile radio communications device having a near field communication capability and being arranged to initiate a communication session between the said remote party and a further mobile radio communications device by way of near field communication with the further mobile radio communications device.

Preferably, the communications session comprises a call session. In particular, the establishment of the communications session within the said further mobile radio communications device can include a domain transfer.

In particular, the establishment of the communications session within the said further mobile radio communicatiois device can comprise transfer of the session from the said mobile radio communications device to the said further device.

In this manner, the said further device can be arranged to be the caller or the callec, for the communication Session.

As an alternative, or in addition, the communication session can comprise a multiparty session to which the said further mobile radio communication device is to he introduced by way of NF'C with the said mobile radio communications device.

As above. NFC can he employed to establish a peer-to-peer communication channel between the two mobile radio communication devices or, alternatively, the NFC can be arranged to set up a secure wireless communication session such as by way of a WiFi or Bluetooth session as appropriate.

The present invention can therefore advantageously provide users with seamless data forwarding (e.g call forwarding and multiparty call joining) from one telecommunication mobile device to another without requiring complex knowledge of the addressing number of the remote party to which is transferred the data.

A NFC compliant telecommunication mobile device allows for the forwarding of a call session (any established communication between a device to a remote device, Tel call, IMS call, messaging session, etc...) by touching the remote NFC compliant mobile device to which the call is to be transferred. The procedure in the short-range communication network further enables the target device to either act as a caller or callee for the transferred call. This is particularly appropriate in cases where the initiating device is the caller and thus is billed for the on-going call, but desires to transfer the call to the target device.

In this scenario, the remote end is the callee and should not he billed but the Target may be billed when the call is transferred to him. The short-range communication can provide such a control where the call transfer may be based on a subscription basis.

Within the present invention therefore there is provided call session transfer, NFC Compliant mobile devices with telecommunication capabilities, access networks (EUTRAN, UTRAN, GERAN, WLAN, ...) with call anchoring capabilities, communication messages for effecting call session negotiation in short-range wireless communication between NFC compliant telecommunication mobile devices, and communication commands for effecting call Session transfer with the access network. The access network to which NFC compliant telecommunication mobile device is attached may be different than the one to which is the remote NFC compliant telecommunication mobile device is attached. As such a domain transfer may be required, !br example between CS and IMS and when a NFC compliant mobile telecommunication device contacts the remote NFC compliant telecommunication mobile device in the near field, call-session information are exchanged either using peer-to-peer (P2P) mode of communication or using an NFC-estahlished secured wireless channel (bluetooth, WiFi). The P2P communication protocol is particularly advantageous in view of at least its speed, power saving and safety characteristics. Therefore, the whole call Session can be transferred to the remote contacted mobile device. As noted, the party that is the recipient of the call can either be the initiator of the call, or the party that receives the call as part of the call session.

It will also he appreciated that the invention further provides for multiparty call establishment and emptying similar aspects as described previously where the network provides a call conference handler/server to mix several calls. The initiating party is able firstly to contact any other devices using the NFC touch paradigm to retrieve participant information prior to providing the conference server with initial conference information and policy. The initiating party is also able to invite further participants by using the NFC touch paradigm to provide to a target device with the conference information fbr that device to join a conference and/or to retrieve the target device infhrmation lbr the initiating device to add the target device to the conference.

Thus, the invention relates to the transfer of a telecomrnuijcatjoi Session negotiated over a short-range (NFC) communication network between devices with telecommunication capabilities. More particularly, it relates to providing short-range wireless communication using NFC technology to retrieve session parameters without the need for the user to know the capabilities of the remote party to which the session (e.g. phone number) is to be transferred and with the ability to transfer telecommunication sessions between telecommunication devices and to ensure service continuity. In said session transfer the device to which the call is transferred can be the device that initiates the call session, (i.e. any end-to-end communication such as CS or IMS calls) or the device that receives the new call session.

Use of NFC technology to negotiate parameters (e.g. phone number, domain used, ) without need for the user to know the remote capabilities (e.g phone number or public user Identifier, or preferred domain) serves to provide a seamless communication transfer/forwarding. Said negotiation can he performed prior to the communication forwarding between two NFC compliant telecommunication devices accessing to any Access System (via GERAN,[.JTRAN, EUTRAN, WLAN, ). In the communication transfer, the device to which the communication is transferred can be either the initiator (caller) or the receiver (callee) of the forwarded communication The invention is described further hereinafter, by way of example only, with reference to the accompanying drawings in which: Fig. I is a schematic illustration of the transfer of a call session between two cell phone handsets; Fig. 2 is a further schematic representation of the call transfer of Fig. 1 as shown in relation to a remote party: Fig. 3 is a schematic representation of the call transfer made in relation to an ongoing conference call; Fig. 4 is a flow diagram providing an illustration of one example of a call transfer method; Fig. 5 is a 1ow diagram illustrating an example of a call transfer method in relation to a multiparty conference call; Fig. 6 is a signal diagram illustrating the first embodiment of a call transfer method within the circuit switch domain; Fig. 7 is a signal diagram of a further example of a call transfer method within the circuit switch domain; Fig. 8 is a signalling diagram of a call transfer method within the IMS domain; and Fig. 9 is a further signalling diagram offering an illustration of call transfer method within the IMS domain.

Near Field Communication (NFC) Technology is becoming increasingly prominent in mobile digital devices such as cellular phones, personal digital assistants. etc... Such a feature evolved from the combination of contactjess identification, and interconnection technologies and typically operates at around 13,56 Mhz over a typical distance of a few centimers. In addition it is highly secure due to the short-range mode of operation and is consequently commonly' designed to he used for payment purpose. thr file sharing or for the exchange of sensitive data, These particular characteristics distinguish NFC technology from others short-range wireless technologies like bluetooth or infrared.

The use of NFC Technology enables communication in a peer-to-peer mode, reader/writer mode and card emulation mode. The peer-to-peer mode is based on the Logical Link Control Protocol as defined in the NFC Forum specifications and which serves to enable NFC Forum peer devices to communicate with each other. The reader mode is mostly used to read data preferably fbrmatted in NFC Data Exchange Format (NDEF) from a reniote NFC compliant device, and the writer mode used to write data on a remote NFC compliant device. Card emulation mode, it is mostly used for payment purpose wherein a mobile device acts as a NFC Tag. Such tags commonly comprises Radio Frequency Identification (RFID) cards or contactiess smartcards.

As noted, the present invention serves to provide fbr seamless call session transfer with seamless session continuity from one NFC compliant telecommunication mobile device to another NFC compliant telecommunication mobile device.

For convenience the NFC-compliant telecommunication mobile device which transfers the call will be named "Initiator" and the NFC-compliant telecommunication mobile device to which is transferred the call will be named Target".

Turning first to Fig. I. there is illustrated a first cellular phone handset 10 which is involved in a voice call 12 with a related network access system 14.

however, in accordance with the present invention, it is required to transfer the voice call session involving the handset 10, by way of a NFC session 16 to another handset 1 8 which is to replace the handset 10 in that call session.

Subsequent to the appropriate negotiation call parameters by way of the NFC 16, as will he described later the handset 18 continues with the voice call session 22 by way of the access network system 20.

Such a call transfer method is illustrated further with reference to Fig. 2 which shows the handsets 10, 18 and networks 14, 20. communication 12 and 22 and which also illustrates a remote party 24 with which initially the handset 10, and subsequently the handset 18, communicates. Thus, with the initiator handset 10, and both the target handset 18 having NFC and telecommunication capabilities.

the NFC connection 16 is established and call session parameter negotiation can occur between the handsets 10, 18.

The access network 14, 20 can comprises as appropriate, a GERAN, UTRAN, EUTRAN, or WLAN network and a communication with the access network through which the initiator firstly conducts its communication with the remote end 24, and subsequently the target 18 conducts its communication can be controlled by way of a call transfer, as discussed in further detail below.

As a further alternative, Fig. 3 illustrates the possibility for introducing a mobile phone handset with NFC capability to a conference call. Thus, as illustrated, a conference call is underway to which handset 28, 30 are parties but wherein, in accordance with the present invention, handset 30 wishes to transfer its involvement in the conference call 26 to a separate handset 32, or indeed simply introduce the handset 32 to the conference call.

Again, as will be described further below, actual contact between the handset 30 and handset 32, and the establishment of a call session as part of the conference call can be achieved by way of a NFC connection 34.

Both initiator and Target can attach to an access network GERAN, UTRAN, EUTRAN, WLAN, ...). The access network to which the Enitiator is attached may not be the same as the one to which the Target is attached. A domain transfer may then be required during a call transfer from the Initiator to the Target. As such, the call can be transferred between the Initiator and the Target from CS domain to IMS domain or from JMS domain to CS domain. The call transferred between the Initiator and the Target may not need a domain transfer, for example: transfer of a CS call from Initiator to the Target or transfer of an IMS call from the Initiator to the target which do not require a domain transfer.

In all scenarios the network can look to anchor a call session so as to enable further call transfer from the Jnitiator to the Target.

As will be evident, the call which can be transferred from the Initiator to the Target comprise a voice call, a video call, or any multimedia call (e.g. a RTP stream). As such, the Initiator may only transfer one call among already established calls with one or more remote parties. An example of the latter aspect is when the user has a CS speech call and a messaging session on a mobile device and decides to transfer only its messaging session to the remote device using the NFC touch paradigm.

The following discussion provides a description of call transfer combinations depending on the domain used.

For CS to CS call transfers, the call is of course based on the Circuit Switched technology. If the Initiator is the caller of the on-going call session, the Initiator negotiates with the Target through the near field wireless communication to check whether the Target accept to be the caller of the call (the Target may be billed for the call transferred depending on the subscription). If the Initiator is the callee of the on-going call session, the Initiator will send the call transfer command so that the Remote End delivers the call data to the Target.

In CS to CS call transfer, both Initiator and Target are attached in the CS domain but the Remote End can be in either in the CS domain or the IMS domain.

If the Remote End is in the IMS domain, the Access System is responsible for anchoring the call and makes the control signalling so that the IMS data from the Remote End is transferred in the CS domain of the Initiator or the one of the Target via e.g. the MGCF element. As such there would be a call data decoding/encoding via the serving MGW of the Target or the Initiator for the user plane.

If the Remote End is in the CS domain, the signalling procedures are as usual and the data are transferred in the CS domain or via the IM CN subsystem if required.

When the Initiator (a) has on-going call with both the Target and the Remote End, (h) is the callee of the on-going call with the Remote End, and (c) wants to transfer the call (Initiator-Remote End) to the Target (Target-Remote End), the following steps are performed: First, the Initiator request the Remote End to establish a call session with the Target. This can be done in IMS domain by a SIP REFER request with the Refer-to header and the Replaces parameter added to the Referred-To URI. The Remote end thus sends a SIP INVITE (in IMS domain) with a Replace header for the Target to replace its on-going dialog by the new the established call session. The Target is in the CS domain, as such it receives an appropriate CS message with the previous information to perform the replacement.

Then, the target replaces the on-going call (Initiator-Target) by the new incoming call session (Target-Remote End).

However if the Target is the caller then the Target initiates a Call Session transfer by means of a new CS Session with the remote who can he either in the CS or the IMS domain. As such a new request is required which should not he part of the on-going dialog between the Initiator and the Target. A new CS TRANSFER message is created for this purpose. I'his CS TRANSFER message initiates a new CS call session in the same way a SETUP message does but including a reference of the call session between the Initiator and the Remote End (e.g. by means of at least TID or Call-ID). Upon reception of this TRANSFER message the Remote End should consider it as a CS SETUP message if it is in the CS domain or as a SIP INVITE message if it is in the IMS domain with the difference that the Remote End should extract the reference value to associate with the old call session and to perform a smooth transition from this old call session (Initiation-Remote End) to the new call session (Target-Remote End) without the need for a ring tone.

For IMS to IMS call transfer, the call is based on the IP-Multjmedia call control Protocol itself based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP). The call transfer requires the following actor as defined in ETSI 1 83 029: the transferee' is the party being transferred to the target (Remote End), the transferor' is the party initiating the transfer (Initiator), and the transfer target is the party that the existing communication is transferred to (Target).

Another element, the SIP Application Server (AS), is involved and remains in the signalling path all over the communication befbre and after the call transfer procedure, thus providing classical charging models.

Both Initiator and Target can ideally support the REFER method (RFC 351 5).

and the Replaces header field (RFC 3891) in case the Initiator already has an on-going communication with the Target. They may support the Referred-By header to indicate the identity of the initiator (RFC 3892). The remote End may at least support the Referred-By headers and Replaces header.

When performing a Call Transfer request, and if the Initiator is the callee of the on-going call, the Initiator sends a SIP REFER request in the original SIP dialog by including the request (]RI of the larget retrieved during the NEC connection establishment, and the Refer-To Header field indicating the public address of the transfer Target. The Replaces parameter is also added to the Refer-to (JRI and an optional Referred-By can be provided to indicate that the Transferor is the Initiator.

When the Initiator has (a) an On-going call with both the Target and the Remote End, (b) is the callee of the on-going call with the Remote End, and (c) wants to transfer the call (Initiator-Remote End) to the Target (I'arget-Remote End), the following steps are performed.

First the initiator request the Remote End to establish a call session with the l'arget. This can he done by a SIP REFER request with the Refer-to header and the Replaces parameter added to the Referred-To tJRL The Remote end thus sends a SIP INVITE (in IMS domain) with a Replace header for the Target to replace its on-going dialog by the new the established call session; or sends a appropriate CS message with the previous parameters to fulfil the same objective. The Target is in the IMS domain, and as such it receives an appropriate IMS message with the previous information to perform the replacement.

However if the Target is the caller then the Target initiates a Call Session transfer by means of a new IMS Session with the remote who can be either in the CS or the IMS domain. Obviously a new request is required which should not he part of the on-going dialog between the Initiator and the Target because it is up to the Remote End to associate the previous call to the new established call. A new SIP J'RANSFER message is created fur this pw-posc. This SIP TRANSFER message initiates a new IMS call session in the same way as does a SIP INVITE message, but including a reference of the old call session between the Initiator and the Remote End (e.g. by means of at least J'ED or Call-ID value). Upon reception of this TRANSFER message the Remote End should consider it as a CS SETUP message if it is in the CS domain or as a new SIP INVITE message if it is in the IMS domain with the di ffërence that the Remote End should extract the reference value to make an association with old call session and to perform a smooth transition from this old call session (initiation-Remote End) to the new call session (Target-Remote End) without the need for a ring tone.

For an IMS to CS or CS to IMS call transfer combination, the principles are the same as for the previous combination with the difference that the Target is transferred the call in a domain which is different from the one to which is attached the Initiator.

in the following description, the procedure is explained in four main steps as depicted in Fig. 4. The first step consists in a call session negotiation between the target and the Initiator to make sure that both Target and Initiator agree on the transfer and the parameters of the call session and on how will be performed the call transfer (Target initiated or Remote End initiated): the second step consists in a call transfer request sent to the Network to perform the data call forwarding to the Target through the appropriate domain; and the third step consists in the completion of the call transfer.

The call transfer request command of the second step can be in the form of a new message carried over the underlying Access System Technology (WLAN, GERAN, UTRAN, ELJTRAN, ...) or in the form of an existing command (e.g. SIP INVITE message, CS SETUP message). The Access System may make use of VCC Application to perform call anchoring. It should he noted that the call transfer command sent to the network can be initiated by either the Initiator or the Target.

For convenience, the following procedure considers the case where the Initiator sends an explicit command to the Network to perform the call transfer from a mobile device to another. Therefore it will be assumed that the Initiator is the callee and that the Initiator has no on-going communication with the Target.

The first step comprises in a negotiation phase between the Initiator and the Target. In a preferred embodiment as illustrated in the figure 3a or figure 4a.

this step is performed as described in the next paragraphs.

The call transfer is conducted upon the decision of the Initiator which performs a NFC connection with the Target. The communication is then performed either using NFC P2P communication protocol or over IP protocol after the establishment of a secured wireless connection thanks to the NFC touch paradigm. It is preferred in a first embodiment to perform the Voice call transfer by using the P2P communication protocol for simultaneous, speediness, battens power-saving and safety reasons.

In a second step, when a transport channel is established between the Initiator and the Target, the Initiator sends a call session transfer request to the Target, over the near field wireless network, including the call session parameters which comprise at least the Target addressing number (e.g. SIP URI), the call direction (caller, callee) the on-going domain used for the call session to be transferred (e.g. CS domain or IMS domain). It further comprises the call session parameters specific to the call depending on the selected domain (this can include the required Quality of Service, media session specific codecs for IP stream, etc...). ft may also further comprise operator restrictions. Such operator restrictions may depend on the user subscription. Therefore a call transfer may not be allowed due to commercial agreements stored in SIM/USIM of the Initiator and Target. As an example if the Initiator is the caller and want to transfer the call, the Target may be billed depending on the subscription and operator agreements. The addressing number included in the call transfer request can he a telephone URI, a SIP URI, or any URI that is used to reach the remote party in the network.

Upon reception of the call transfer request sent by the Initiator over the near field wireless network, the Target analyses the received call session parameters.

The Target may not accept the call transfer as it may not be able to provide the required Quality of Service, or is not able to handle the call transfer, or due to operator restrictions. The Target is able to select the preferred domain for the call which can be done automatically based on user's or operator's preferences that can be stored in SIM/IJSIM. This preferred domain is added in the answer as well as the addressing number associated with the Target. The preferred domain and addressing number can he represented a single [IRI. These parameters will be used by the Access Network to reach the Target and forward the call accordingly.

As an additional feature, the Target may also add quality parameters preferences. Actually the Initiator is aware of the Remote End capabilities (e.g. Exchanged during the SDP media negotiation phase) and is able to inform the Remote End capabilities to the Target. For instance for speech call session the target would include supported codecs and in return the Initiator would return the one supported by the Remote End. The purpose is to accelerate the potential negotiation phase between the Target and the Remote End for the call transferred.

The Target sends a Call Transfer Answer over the short-range wireless network by including a status code to ascertain whether the call transfer can be performed. En present scenario, the Target will prepare to receive the call (it may Registers in IMS domain if not already registered or actively wait for CS incoming call in case of CS domain selected).

The initiator then receives the Call Transfer Answer and analyses the received message. The received Call Transfer Answer contains a status code indicating whether the call transfer is agreed or not. In this scenario and according to the defined assumption stated before, the Initiator is responsible of sending the call transfer request to the Network.

The third step of this embodiment of the present invention relates to the call transfer procedure with the network which is initiated by the Initiator according to previously defined assumptions. In a preferred embodiment this procedure is as described in the following paragraphs and is illustrated in figures 3a, 4a.

The Initiator sends a Call Transfer Request to the Access Network. This Call Transfer is transported over the required transport protocol depending on the currently used access system technology (e.g. GERAN, UTRAN. EUTRAN, WLAN, ...). This Call Transfer Request carries the necessary information for the Remote End to set up a call session with the Target and forward the call accordingly up to the Target over the requested domain (CS or IMS) via the appropriate Access System.

Thus the Call Transfer Request is managed by the Access Network which cheeks whether the call session can be transferred. This should be allowed in most cases as the operator conditions should be negotiated during the first step.

If the call transfer is rejected for some network operator reasons (unable to reserve the resources, etc...) an error status code is sent back in the answer.

Otherwise a data path is established to route the call data to the Target, based on the Target related information (required QoS, Target address number in the form of a URI, listening port, etc...) and vice versa as depicted in next clause.

The fourth step consists in the reception by the i'arget of the incoming call and completion of the call transfer procedure. Optionally the Initiator and Target acknowledge each other over the short-range wireless connection. Actually they should implicitly he able to determine whether the call transfer has succeeded or not (e.g. by implementing timers, deducing the success when receiving the call data or receiving a notification from the network).

However, in the case where the Initiator waits for call transfer network acknowledgement and does not receive it when a defined timer expires, the Initiator may explicitly sends a Call Transfer Finished to the Target over the short-range wireless network. The Initiator may also have lost the short-range wireless connection and in should then consider that the call transfer has failed, and go in the appropriate state.

In this fourth step the Target and Initiator acknowledge the completion of the call transfer procedure. As such, the Call Trans fèr Finished! message is preferably sent by the Initiator which is then acknowledged by the Target. The Initiator may think that the call transfer has failed because of having not received the network acknowledgement but the Target may had effectively successfully receive the call and thus set a success status code in the acknowledgement. Thus the Initiator should revise its call transfer result and assume that it was a success.

However if the Target has successfully been transferred the call (reception of the call data) and does not receive a Call Transfer Finished message after a pre-defined period of time after the starting of the procedure in step 3, the Target should send a Call Transfer Finished Message to the Initiator and wait for its acknowledgement. If no acknowledgement is received or if the connection is lost, the procedure is finished and the Target and Initiator should assume that both sides are aware of the completeness or failure of the Call Transfer procedure.

With regard to Fig. 6, there is provided a signalling diagram illustrating an example of the signalling arising between the initiator 10 and target 18 handsets of Fig. 1, the related circuit switched access network 36 and hand remote device 38 such as that illustrated in Fig. 3.

Current signaling 14 represents an active voice call and, at the start of a call transfer procedure and NFC connection 42 is established and a negotiation call transfer request 44 sent from the initiator 10 to the target 1 8, which target 18 then replies with a negotiation call transfer answer 46. The initiator 10 then delivers a negotiation call transfer acceptance request 48 before sending a call transfer request 50 to the access network 36. The access network 36 then delivers a call transfer request 52 to the remote end device 38, which device 38 responds to the call transfer accept message 54.

Subsequent to this procedure, the active voice call between the initiator 10 and the remote end 38 is placed on hold and then, fbr transfer of the call, a contact signal 56 is delivered from the remote end 38 to the access network 36 which, in turn, delivers a contact -setup signal 58 to the target 18 which initiates ringing within the target handset 18, the target 28 can then return a connect signal 60 to the access network 36. A connect -OK signal 62 is then delivered from the access network 36 to the remote end 38 which, in turn, responds with a connector acknowledge signal 64 which, in turn, initiates a connection acknowledge signal 66 from the access network to the target 1 8.

A new call path 68 is then established involving the target 18 rather than the initiator 10 and data call forwarding 70 can he provided as indicated.

Then, to conclude a notification signal 72 can he delivered from the remote end 38 to the access network 36 and a notification to acknowledgement returned if within the IMS domain.

A call transfer accept signalling message is then delivered from the access network 36 to the initiator 10 and a circuit switch release exchange can occur between the access network and the initiator 10, and the circuit switch release exchange 76 can occur between the access network 36 and the initiator 10 and a release exchange 78 can be initiated between the access network 36 and the remote end 38.

For completion of the call transfer, a call transfer finished signal message 80 can be delivered from the initiator 10 to the target I 8 which can respond with a call transfer finished acknowledgement 82.

It should be appreciated that the signalling illustration provided by Fig. 6 relates to a circuits switched circuit switched call transfer from the initiator 1 0 to the target 18 in a particular embodiment of the present invention and which the remote end 38 can be in the circuit switch IMS domain, but in which the transfer is remote end initiated.

Turning now to Fig. 7, there is provided an illustration in which the transfer is target initiated.

Again, an initiator 10, target 18. circuit switched access network 36 and remote end 38 are involved since signaling then commences with an active Voice call 84 established by the initiator 10 with the access network 36 and remote end 38.

In this embodiment at the start of the call transfer, a NFC connection 86 is again established between the initiator and target and a negotiation call transfer request 88 then delivered from the initiator 10 to the target 18, within a negotiation call transfer answer 90 returned from the target 18 to the initiator 10.

The active voice call between the initiator 10 and the remote end 38 is then placed on hold and a negotiation call transfer accept request 92 is sent from the initiator 1 0 to the target I 8. The target 1 8 responds with a contact signal including reference parameters 94 which is delivered to the access network 36 as part of the start of the transfer request procedure, and the access network 36 responds with a contact signaling with reference parameters 96 delivered to the remote end 38 and wherein the specific parameters indicates the target for the call so no ringing at the remote end is required and a smooth-handover can be achieved.

A connection exchange 98, 100 or 102 then occurs between the remote end 38 and the access network 36, and then the access network 36 and the target 18 before a connection acknowledgement signal 104 is delivered from the access network 36 to remote end 38.

Then a new call path 106 is established involving the target 18, rather than the initiator 10 and, as part of the completion call transfer procedure, a negotiation call transfer accept acknowledgement 108 is delivered from the target 18 to the initiator 10 and a circuit switch release exchange 110 occurs between the initiator 10 and the access network 36, and a release exchange occurs between the access network 36 and the remote end 38.

With call transfer completed, and the voice call session Id maintained for a defined period, data call forwarding signalling 114 can be conducted between the remote end 38, the access network 36 and the target 18 as illustrated.

Turning now to Fig. 8 there is illustrated signalling arising within a IMS call transfer procedure from initiator to target and which, as with Fig. 6, is remote end initiated.

This signalling diagram again involves an initiator 10, target 18. and an access network 36 and remote end 38 in which an active voice call 116 is in place involving the initiator 10.

Again, with the start of the call transfer procedure, a NFC conhlection 118 is established between the initiator 10 and target 18 and the negotiation call signalling exchange between the initiator 10 and target 1 8 is then conducted as illustrated in 120, 122 and 124.

Subsequent to this exchange. a call transfer request is delivered from the initiator 10 to the access network 36 which leads to a call transfer request/accept exchange 128, 130 between the access network 36 and the remote end 38.

Prior to the call active voice call being placed on hold between the initiator 10 and the remote end 38, a call transfer accept signal 132 is delivered from the access network 36 to the initiator 1 0.

A contact, setup invite, connection establishment signalling exchange 134-144 is then established as illustrated and which can lead to ringing within the target 18 device.

Subsequent to the connect acknowledgement 144, a new call path 146 is then established between the access system and the remote end and in which the target 18 is involved rather than the initiator 10.

Subsequently, notification signalling exchanges 148, 1 50, 152, 154 are provided as indicated and which allow for the establishment of [P speech data flows 156 between the remote end 38 and the access system 36 and between the access system 36 and the target 18.

A session release signalling exchange between the access system 36 and the initiator 10 is then provided as illustrated at 158 and a further session release exchange 1 60 is conducted between the access system 36 and the renlote end 38.

A call transfer finished exchange 162, 164 between the initiator 10 and target I 8 then occur at completion of the call transfer.

With reference to Fig. 9, there is again shown signalling relating to an IMS to IMS call transfer from initiator to target but, as with Fig. 7, on this occasion the transfer is target initiated.

Again the illustration is provided with an initiator 10 and target 18, and access network 36 and remote end 38 and with an active voice call 166 established by way of the initiator 10.

As before, at the start of call transfer procedure, a MFC connection 165 is established between the initiator 1 0 and the target 1 8 so as to allow for negotiation call transfer request/answer 1 70, 172 signalling exchange between.

Subsequent to the voice call between the initiator and the remote end being placed on hold, a negotiation call transfer acceptance request 174 is delivered from the initiator 10 to the target 1 8 and which leads to a contact signalling exchange 176-186 as illustrated which, with a specific parameter being provided within the signalling 1 76, 178 so as to provide for a smoother handover without any ringing being required at the remote end 38.

Upon completion of the connect signalling exchange, a new call path 188 is established but this time with the target 1 8 rather than the initiator 10.

As part of the call transfer completion signalling, a negotiation call transfer acceptance acknowledgement 190 is sent from the target 1 8 to the initiator 10 and, subsequently, a IMS release signalling exchange is conducted between the initiator 10 and the access network 36, and also 1 94 between the access network 36 and the remote end 38.

Subsequent to completion of the call transfer data forwarding signalling flow 1 96 is again established between the remote end 38 and the access network 36 and the target 18.

In the following description, the procedure as depicted in Fig. 5 is explained further.

A call conference can either he initiated in the IM CN subsystem or the CS domain and so both cases should he allowed.

It should be appreciated that the Target to which is given conference information should join the conference in the appropriate domain, which can be deduced according to the IJRJ syntax. Preferred domain and/or restriction should be advertised to the Target. Actually the Target may try to join a call in the CS domain while the conference is held on the IMS domain, hopping that the conference call is anchored in the Network and that the domain transfer is performed by the Network, but this may result in a failure if the network do not support it.

According to the conferencing model, the signalling needs to be centralized, and the media can he centrally mixed, distributed, or even muiticast. The conference to establish can bridge participants that have different capabilities and that can join the conference by different means (dial-in, dial-out, scheduled, or ad-hoc).

In the multiparty framework, the Focus hosts a SIP conference and maintains SIP signalling relationship with each participant in the conference.

The Initiator is a participant and can be the initiator of the conference (e.g. the Focus of the conference). The initiator can advertise conference information to the Target using NFC communication established link.

The Conference Server may allocate and publish a conference URI. The Conference URI may be well constructed using a Globally Routable User Agent URI (GRUU).

The first step consists in a negotiation phase between the Initiator and the Target so as to give the conference information and to ascertain whether the Target dial in to the conference or is invited by the Initiator.

The second step consists in the addition of the Target to a conference.

Note that the Initiator or the Target may be the first participant so the INVITE sent to join a conference may activate the conference.

-In the case where the Initiator is a participant, and if the conference has not been established yet, the Initiator can retrieve the Target information (e.g. SIP t]R1) to populate the conference information to send to the conference server.

If the Initiator is already in a SIP session with a Remote End, the Replaces header should he supported so to migrate to a centralized conference when adding one or more Target(s) to the conference.

The Target can either dial in to a conference or be invited to/from it.

In the first case the Initiator provides the conference information to the Target.

so that the Target is able to dial in to the conference advertised by the Initiator.

In the second case the Initiator retrieves the 1'arget Information so as to Invite it to the conference if possible.

If the Initiator is the focus of a conference, it can add the Target (if allowed) to the conference by firstly retrieving the Target infbrmation (tJRL capabilities, ) and notifying all other participant that Target has joined the conference.

When the Target Dial in to a conference, the Target can use the Conference URI retrieved in the first step, and set the Request-URI in the INVITE accordingly.

Then normal SIP communication takes place.

The Target can also use the Dialog Identifier instead of the Conference IJRI.

This Dialog Identifier is learned during the first step. As such the Target can send a request to the Focus containing a Join header field containing a dialog Ii) of one leg of the conference (a dialog between another participant and the focus) When the Initiator is not the focus but a participant of the conference and want to bring the Target into the conference, the Initiator can send a REFER SIP message to the conference URI. Upon receipt the conference server (the focus) should send an INVITE to the Target identified by the Refer-To SIP URI containing a Contact header field with the conference URI and the "isfhcus" feature parameter according to RFC 4579.

When the Initiator is the focus and wants to bring the Target into a conference, the Initiator can send an INVITE request to the Target. The INVITE message contains a Contact header field with the Conference URI and the "isfocus" feature parameter according to RFC 4579.

It is also possible in existing use cases that the Initiator request the Target to dial in to a conference using a conference UR!. This is not a scenario relevant for current invention because this is achieved during the first step where the Target can be requested to Dial in into the Conference.

Thus the need exists to develop a short-range communication system including to or more telecommunication mobile devices with NFC capabilities, network accesses with supplementary services such as call forwarding capabilities. The desired system, devices and method should be capable of providing call Transfer and multiparty functionality between NFC compliant telecommunication mobile devices in an easy, intuitive and seamless manner, where the session transfer and multiparty functionality are initiated using the touch paradigm in a secured way while avoiding the user that performs the call transfer to know the characteristics of the remote mobile device (phone number, desired domain, etc...).

The method of the invention can advantageously also ensure that the remote party is able to he transferred the call prior any procedure in the access network.

Claims

CLAIMS: I. A method of establishing a communication session between a second mobile radio communications device and a remote party and including the step of initiating the communications session establishment in the second mobile radio communications device by way of near field communication with a first mobile radio communications device already in communication with the said remote party.
2. A method as claimed in Claim 1, wherein the communications session comprises a call session.
3. A method as claimed in Claim 1 or 2. wherein the establishment of the communications session within the second mobile radio communications device can include a domain transfer.
4. A method as claimed in any one or more of Claims I to 3, wherein the establjslmient of the communications session within the second mobile radio communications device can comprise transfer of the session from the first device to the second device.
5. A method as claimed in any one or more of Claims I to 3, wherein the communication session comprises a multiparty session to which the second mobile radio communication device is to be introduced by way of the first mobile radio conlmunjcatjons device.
6. A method as claimed in Claim 5, wherein the first communication device is arranged to transfer its participation in a conference call to the second mobile radio communications device.
7. A method as claimed in any one or more of Claims I to 6, wherein the near field communication serves to establish a peer-to-peer communication channel between the first and second devices.
8. A method as claimed in any one or more olClajms 1 to 6, wherein thc near field communication serves to set up a secure wireless communication session.
9. A method as claimed in any one or more of the preceding claims wherein near field communicatjn provides for the negotiation of communication device parameters.
10. A method as claimed in Claim 9, wherein the said negotiation is conducted prior to the establishn-ent of the communication session.
11. A mobile radio communications device arranged for communicating via a communication session with a remote party by way of a mobile radio communications network, the mobile radio communications device having near field communications capability and thereby being arranged to have the communication session initiated by way of near field communications with a further mobile radio communications device already in communication with the remote party.
12. A device as claimed in Claim 11 and arranged such that the establishment of the communications session within the said mobile radio communications device can comprise transfer of the session from the said further device to the said device.
13. A device as claimed in Claim II, and arranged such that the communication session can comprise a multiparty session to which the said mobile radio communication device is to be introduced by way of the said further mobile radio communications device.
14. A device as claimed in Claim 11, 12 or 13, wherein the near field communication is employed to establish a peer-to-peer communication channel between the said further and the said mobile radio communication device.
15. A device as claimed in Claim 11, 12 or 13, wherein the near field communication is arranged to set up a secure wireless communication session.
16. A mobile radio communications device arranged for communication via a communication session with a remote party and by way of a mobile radio communications network, the mobile radio communications device having a near field communication capability and being arranged to initiate a communication session between the said remote party and a further mobile radio communications device by way of near field communication with the further mobile radio communications device.
17. A device as claimed in Claim 16 and arranged such that the establishment of the communications session within the said further mobile radio communications device can comprise transfer of the session from the said device to the said further device.
18. A device as claimed in Claim 16 or 17 and arranged such that the communication session can comprise a multiparty session to which the said further mobile radio communication device is to he introduced by way of the said mobile radio communications device.
1 9. A device as claimed in Claim 16, 17 or 18, and arranged such that the near field communication is employed to establish a peer-to-peer communication channel between the first and second devices.
20. A device as claimed in Claim 16, 17 or 18, and arranged such that the near field communication is arranged to set up a secure wireless communication session.
21. A method of establishing a communication SCSSiOfl between mobile communication devices and substantially as hereinbefore described with reference to and as illustrated in, the accompanying drawings.
22. A mobile radio communications device arranged for communicating via communication session with a remote party and substantially as hereinbefore described with reference to the accompanying drawings.