Patent Application
20130059573
The current invention relates to a mobile communication devices connected in a mobile communication access network and the initiation of multi party communication by the mobile communication devices.
General initiation of telecommunication is towards a single party. Whether call, message or other wanted communication the mobile communication access network, and the standardization effort for that, allows such only towards one party at the time. The telecommunication network (core network) has however known features to bind for example one by one set-up calls in a single conference.
Manufacturers of terminals recognized this problem and have implemented special terminal based high end programs that take away the effort for the user of such a terminal. The user can pre-select multiple destination parties and the special program takes care of initiating one by one. Drawback of this is that a lot of “non chargeable airtime” is lost due to the extensive signaling required for each party to be connected.
Detailed background information is provided in various 3 GPP Technical specifications. Most important to name for the purpose of the described invention; messages involved in setting up a voice call TS 24.008, for messages involved in SMS transport TS 24.011 and TS 23.040, for MAP messages TS 29.002.
Also services in the core network were developed which allow a user to pre-program groups and allow for simple initiation by triggering the service with the identity of such a preprogrammed group. The service then takes care of setting up a conference or copying a SMS to multiple parties.
Another well known service is the scheduling of a conference. The user requests a conference managing service to reserve a time slot and a code. Conference details are send prior to the conference to the participants by for example e-mail. Typical details comprise organizer, number to call in, code for access to the conference and starting time duration. Apart from the upfront effort also the charging aspect must be taken care of. A participant calling in will normally bear the cost for his link. Reversal of cost requires use of toll free numbers (charged to the conference requestor) or mechanisms of reversed charging.
From the above it is apparent that there is a need for a method and system of initiating ad-hoc communication to multiple parties having for the user the easiness as provided by the high-end terminal application but without the drawback of the extensive use of airtime for setting up the communication.
The invention discloses a method to initiate a communication to multiple destination parties by including the multiple destination parties in a multiple destination party container, and subsequently include the container in the communication initiating message.
In first aspect it relates to a mobile terminal operational connected to a radio access network in a telecommunication network comprising the radio access network and a core network. The mobile terminal assembles the multiple destination party container from user input, includes the container in a communication initiating message and transmits the message to an access node of the core network via the radio access network.
In second aspect it relates to an access node to the core network. The access node receives the communication initiating message via the radio access network, retrieves the multiple destination party container and initializes the communication to multiple destination parties as indicated in the multiple destination party container.
In a further aspect a mobile station and an access node are disclosed, specially adapted to perform the above functions.
Solution for the problem identified in the background is provided, with reference to
The basic invention will be further detailed with a number of embodiments.
In this embodiment the mobile station initiates a conference call by including the multi destination party container in a set-up message. As outlined in background the currently standardized method is to use a SET-UP message containing an information element (IE) ‘5E’ in which a single destination party is identified (called party BCD number).
This IE can for compatibility reasons not just be replaced by the container. For that reason a new IE (for the further description identified as example ‘5F’) is defined containing the multi destination party container. The usage shall be compatible with access nodes to the core network which are not capable of detecting and handling the new IE ‘5F’ and like wise access nodes enabled for the new IE ‘5F’ shall be able to handle SET-UP messages from mobile station requesting a call set-up to a single party based on IE ‘5E’.
The mobile station shall therefore include also the IE ‘5E when using the IE ‘5F’. The length field of the IE ‘5E’ shall be set to 0 and no called party number included. For an enabled access node this indicates that IE ‘5F’ is present and that shall be used for setting up the communication. A not enabled node will return an error message back to the mobile station as no called party number is provided.
The lower transport layers of the radio network are transparent for the message contents independent of the IE's used in the messages.
The layout of the new IE ‘5F’ is given in
It shall be understood that for the non IE type embodiments described hereafter there is more freedom in defining the layout. In that case the above described lay out is a mere example.
The mobile station assembles the IE and includes this in the set-up message. The radio network transports the message to the access node which in this case is the MSC to which the mobile station is operational connected. The MSC detects the length field of IE ‘5E’ being 0 and checks for IE ‘5F’ if not present an error message is returned to the mobile station. Else the MSC starts with setting up the conference call with the multiple parties identified in the IE ‘5F’. When the IE ‘5F’ is used IE ‘6D’ (additional called party information) has no meaning or will be added to each called party in IE ‘5F’.
Although setting up a conference call in a MSC is known art, there are some special considerations. As there is no longer a single party connection, feedback to the mobile station has to be arranged differently. The method as given below includes examples of the alternative feedback.
The MSC starts with setting up a media context to which the calling leg is attached. In order to signal the mobile station that currently no called party is attached the MSC connects a ring tone generator or an announcement machine to the media context. Typically announcement is “waiting for participants to connect”. In the same time the MSC sends out the ISUP-IAM messages for each called party identified in the IE ‘5F’. When a first called party answers the call leg of that party is connected to the media context and the announcement is removed. As an option the MSC can play an additional announcement to the answering party telling that the party is invited to a conference call by number or other identification of the mobile station. In the same time a comparable announcement is injected to the media context that number or other identification of the answering party has connected. After playing the announcements the answering party is connected to media context. This will continue till all answering parties are connected. Parties not answering before a time out will not be connected. As an option the MSC can finally play an announcement identifying all parties not having answered. When a party disconnects also an announcement can be played to the media context identifying the disconnected party. The initiating mobile station can put the conference on hold meaning that its call leg to the conference is put on hold but that other parties still have voice contact with each other. When the mobile station disconnects either all remaining parties are disconnected or the media context is maintained for the remaining parties till the one but last called party disconnects.
Such can be set as parameter in provisioning of the MSC.
From charging point of view the latter option is less interesting as the mobile station will bear the cost of all called legs. CDR's are generated with the same call reference number for each calling leg. In the latter option the mobile station would not be in control of the cost.
In this embodiment the mobile station initiates a conference call by including the multi destination party container in a SMS message send prior to sending the set-up message. The format of the container maybe as defined for the new IE ‘5F’ as stated in the first embodiment
In order to recognize the situation the ‘5E’ is not empty (length field=0) but the own IMSI is stated as called party number by the mobile station. Length field=0 would mean that the MSC would search for a ‘5F’ container. The MSC will now look for a previous received SMS with the same IMSI. Therefore the MSC has a separated storage facility for these SMS messages. The MSC sets-up and handles the conference call as described in the previous embodiment using the container in the stored SMS.
The MSC requires the SMS contents for setting-up the conference call. This means that the MSC must receive the SMS and recognize that is containing the multi destination party container and is not just a regular SMS. In order to make the SMS recognizable, the mobile station does not include an SMSC address as destination in the SMS but its own IMSI. As explained in the back ground the mobile station can send SMS messages via the MSC but also via the SGSN when having connection to that. Depending on the configuration and current access several options exist for getting the SMS to the MSC.
In the first case the mobile station is capable of selecting whether the SMS is send to the MSC or the SGSN (or currently no connection to the SGSN is available). In this case the MSC receives the SMS. As explained the MSC has not a transport layer as normal operation would be direct forwarding to a SMSC. The MSC has however an interface function that receives the SMS via the radio link layer and forwards via the MAP interface. This link interface is adapted to recognize that the SMSC address is equal to the IMSI of the mobile station sending the SMS. In that case the SMS is not forwarded to a SMSC but stored in the storage facility for multi destination party containers.
In the second case the mobile station has connection to a SGSN and will try to send the SMS via the SGSN. Like wise the SGSN has no transport layer function but an interface function as the MSC. The interface function recognizes the SMSC address to be an IMSI equal to the sending mobile station. The interface function reacts by sending a not supported error back to the mobile station (error #69, not supported service). The standard reaction of the mobile station is then to retry sending the SMS to the MSC. The MSC receives and handles as in the first case.
In the third case the SMS is received by the SGSN and the link interface recognizes the SMSC address being the IMSI of the sending mobile station. No error message is produced but the interface function uses the same MAP-MO-FORWARD-SMS as it would use towards the SMSC in normal SMS cases. The interface function uses however not the destination field (which normally would contain the SMSC address) but uses the global title of the own VMSCs (or direct single address of an own VMSC) covering the same area. The MSC receives the SMS and acts as in the 2 previous cases.
In this embodiment the mobile station initiates a communication to multi destination parties by SMS. As in the second embodiment the mobile station sends first an SMS including the container having its own IMSI as SMSC address and having a called party information element also containing the IMSI.
The layout of the container may again be as defined in the first embodiment. After that the actual SMS is send as a single SMS or a concatenation of SMS messages. All of them having the SMSC address being the own IMSI. As the SMSC address it self must be known the called party Information element inside the SMS contains the actual SMSC address to be used.
The MSC receives the SMS with the container and stores that. Then the second SMS (or concatenation of SMS) is received. As it comes from the same source, being the IMSI of a mobile station as is already stored, it is recognized as the actual SMS to be copied and send to the multiple parties as indicated in the stored container. The MSC therefore replaces the called party information element in each copy with a destination from the container and forwards to the SMSC as originally indicated in the called party field.
As the previous embodiment some different cases can exist; Where the mobile station can select the MSC or there is currently no SGSN connection the SMS messages will be received by the MSC.
If there is connection to a SGSN, the interface function can produce a ‘not supported’ error so that the SMS messages go to the MSC or the SGSN can forward to the MSC via the MAP connection.
This embodiment is comparable to the first embodiment only now applied to SMS. The mobile station includes the called party information element with length field=0, and adds a multi destination party container as new defined information element. The layout of this information element is identical to that of the first embodiment. The SMS message, or concatenation of SMS messages, is send by the mobile station. The actual multiplication of the SMS message can be handled in MSC, SGSN or the SMSC. The MSC and SGSN cases are similar to the second embodiment. It requires that the interface function in MSC or SGSN is capable of detecting a called party IE with length=0. It is therefore required that interface function inspects the actual contents of a received SMS and if a container is present then copy the SMS for each intended recipient, remove the container and add the intended recipient in the called party IE. The SGSN has the option to produce an error or transport via MAP to the MSC so that copy and replacement are performed in the MSC. These are however less efficient in the case of a SMS. Alternative is that the SMS is transferred transparently by either MSC or SGSN to the indicated SMSC and that the SMSC detects the presence of the container and performs the copy and replace and subsequent forwards to intended recipients.
In this embodiment the mobile station extends the SMS message or concatenation of SMS messages with one additional SMS message containing the multi destination party container so forming a new concatenated SMS. This is outlined in
SMS messages are transported between mobile station and the MSC or SGSN via the radio interface. This interface has several layers where the application layer is the highest. The application layer is supported by the transport layer, which is supported by the relay layer, which is supported by the connection layer, which is finally supported by the basic radio protocols. For a detailed view reference should be made to the describing standard 3GPP TS 24.008 and TS 24.0011.
Between the MSC or SGSN and the SMSC messages are transported using the MAP interface. The current standards have not defined the presence of a transport layer and application layer in the MSC or SGSN. Instead an interface function is identified. The interface function receives RP (relay layer protocol) data containers from the Relay layer, containing mobile station originating SMS messages, unpacks these and uses the elements to reassemble MAP messages. Main reason is to leave the transport level addresses and high level error reporting unchanged. Typically these will be changed inside a transport layer. For terminating SMS messages towards the mobile station the process works reverse.
The implementation of the SMS part of stated embodiments is made by special adaptations in the interface function.
After having the received RP data container unpacked the interface function first checks if the SMSC address stated might be equal to the stated IMSI of the mobile station sending the RP data container. In that case the SMS is intended to be used for multiple party communication set-up. When not the IMSI of the mobile station a second test checks if the information element containing the called party number has a length field=0. In that case the SMS requires copying and including of called party numbers as contained in a MDPC. If both test are negative it is a regular SMS. The interface function assembles the MAP message and forwards to the SMSC as indicated by the mobile station.
If the first test is positive the interface function in the access node has 3 options. If the access node is a SGSN then it can return a #69 error back to the Mobile station indicating not supported service. If the access node is a SGSN then the second alternative is to assemble a MAP message but for ward to the V-MSC instead of the SMSC. The third option if the access node is a MSC is to check if the information element called party is equal to the IMSI of the sending mobile station. If that is the case the MDPC is retrieved and stored in the MDPC store of the MSC. If not the mobile station IMSI it is assumed to be the SMSC address and the SMS was intended for multi party communication. The interface function then retrieves the MDPC from the store identified by the IMSI of the SMS sending mobile. The original information element called party is saved as SMSC address and subsequently used as destination in the copies of the SMS. The original called party IEs in the copies are replaced by the party numbers as identified in the MDPC. Each copy is subsequently assembled in a MAP message and forwarded to the indicated SMSC.
If the second test is positive the unpacked RP data container is checked if an MDPC information element is present. If this is the case the MDPC is retrieved from that. Else the MDPC is retrieved from the last SMS of a concatenated set of SMS messages. The latter requires the interface function to receive all SMS messages belonging to the concatenation before handling them. In either case the MDPC contents is used for inclusion in the called party IE in the copies of the SMS. The copies are assembled in MAP messages and forwarded to the SMSC as indicated by the sending mobile station.
In case the access node is a MSC it can also receive SMS messages via the MAP interface. Normally these would be terminating SMS messages for the mobile station. The interface function is further adapted, see
In case of a call set-up message this is only received at the MSC. The standard MSC has a call handler that will build the connection by issuing an ISUP message into the core network. The actual voice connection is made via a media gateway controlled by the call handler. Normally a set-up received at the call handler will result in setting up a single connection with a called party. For enabling the embodiments the call handler has been adapted with additional functions, see
If positive a second check is made if the MDPC information element is present (example 5F). If this check is positive the MDPC is retrieved from this IE. Else the MDPC is retrieved from the MDPC store based on the IMSI of the call requesting mobile station. The call handler then uses the MDPC to set-up a conference call to the parties as identified in the MDPC.
Although the invention is described with a few dedicated examples, it will be apparent to a person skilled in the art that the basic principle of adding a multi destination party container might be used in various situations where a mobile station wants to initiate communication to multiple parties.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/CN09/01254 | 11/13/2009 | WO | 00 | 6/28/2012 |
