DESCRIPTION OF PREFERRED EMBODIMENTS

[0032] In the following a mobile telecommunication system is described with reference to FIG. 1 , in which text messages such as short messages concerning for example service information are sent between a controlling network element 1 of an intelligent network IN and a mobile station 2 .

[0033] A service control point 1 which is the controlling part of the intelligent network IN is connected via MAP (Mobile Application Part) interfaces to a short message service center SMSC 3 with MAP interface, and to a SMS (short message service) gateway and SMS interworking MSC (mobile switching center) 7 . The SCP 1 is further connected via an intelligent network application protocol INAP interface to an entity 4 including a mobile switching center MSC, a visitor location register VLR and a service switching point SSP. The entity 4 is also connected via MAP interfaces to the above mentioned SMSC 3 with MAP interface and the SMS gateway and SMS interworking MSC 7 and to a home location register HLR 5 . Further, it is connected via a base-station system MAP (BSSMAP) interface to at least one base transceiver station 6 which is connected via an air interface, i.e. via corresponding channels SDCCH, SACCH, FACCH, to the mobile station 2 . The above mentioned SMS gateway and SMS interworking MSC 7 is further connected to a short message service center SMSC 8 with a short message relay service element SMRSE interface via a X.25 interface.

[0034] For the sake of simplicity all interfaces (MAP, INAP, BSSMAP, X.25) shown in FIG. 1 are illustrated as direct connections between the corresponding network elements. However, it is to be noted that also other network elements may be involved through which messages are transmitted. Furthermore, although illustrated as separate network elements, the mobile switching center MSC 4 may include the SMS gateway and SMS interworking MSC 7 to form one entity. Likewise, other functional blocks shown in FIG. 1 can be combined or even broken down into smaller functional blocks carrying out part of the overall function.

[0035] The operation of transmitting short messages relating for example to service specific information from the service control point SCP 1 to the mobile station 2 is as follows.

[0036] Short messages are always routed to the mobile station 2 via a short message service center SMSC. First, the short message is sent from the SCP 1 to the SMSC 3 or SMS Interworking MSC 7 via a SMS interworking functionality. This interworking functionality can reside either in the SMS interworking MSC 7 or in the SMSC 3 . For sending of the short message the mobile application part MAP protocol is used. Then, also by using the MAP protocol, the short message is forwarded to the mobile switching center MSC via a SMS gateway functionality. Said SMS gateway functionality can reside either in the SMS gateway MSC 7 or in the SMSC 3 . Thereafter, the short message is sent to its destination, i.e. to the mobile station 2 via the base transceiver station 6 , like any mobile terminating short message.

[0037] To operate in the above described manner, the service control point has to implement an originating and terminating short message service which comprises specific MAP functionality. In particular, these functionality is MAP-Forward-Short-Message for sending a short message from the SCP to the SMSC and to receive a status report as confirmation, and Send-Routing-Info-For-SM for sending routing information used for said status report. Said particular functionality will be described later.

[0038] As mentioned above, for transmitting the short messages, the MAP protocol is used. For the MAP protocol, in combination with transmission of short messages, there are several MAP services defined. The MAP services are used to establish a communication connection, to check service requirements, to request and receive service parameters, to send corresponding messages, to close communication connections and the like.

[0039] In the following, a method for transmitting short messages between a SCP and a mobile station via a SMSC is described with reference to FIG. 2 .

[0040] In FIG. 2 , when the SCP 1 wishes to send specific information concerning for example service information to a mobile station 2 participating on said service, the procedure is started (step S 1 ). In step S 2 , a first communication connection is established by the SCP 1 to the SMSC 3 . Thereafter, in step S 3 , a short message, i.e. said specific information, is sent from the SCP 1 to the SMSC 3 . The SMSC 3 acknowledges the receipt of the short message (step S 4 ). Thereafter, the first connection between the SMSC 3 and the SCP 1 is closed. The SMSC can forward the short message to its destination, i.e. to the mobile station 2 , as described above (step S 5 ).

[0041] In step S 6 , it is checked, whether a confirmation of the forwarding of the short message is required, i.e. whether it is required to notify to the SCP 1 from the SMSC 3 about the outcome of the short message sent to the mobile station 2 . The confirmation may be performed by sending a status report from the SMSC to the SCP.

[0042] If in step S 6 no confirmation is required, the process proceeds to step S 10 and ends, i.e. only the acknowledgement of step S 4 has been sent to the SCP. On the other hand, if in step S 6 a confirmation is required, step S 7 follows, in which routing information of the SCP 1 is requested and received by the SMSC 3 . The routing information can be requested from the home location register 5 or from the SCP 1 itself. It is decided in the implementation phase by the operator where the query of location information is to be made. A description of the two cases will follow below with reference to FIGS. 5A and 5B .

[0043] After the SMSC 3 has received the routing information in step S 7 , a second connection between the SMSC 3 and the SCP 1 is established. Via this second connection, the SMSC forwards a status report as a short message to confirm the sending of the specific information, i.e. the short message of step S 3 to the mobile station 2 (step S 9 ). After closing the second connection, the process is finished in the step S 10 .

[0044] Message dialogues between the respective network elements involved in the above described procedure are illustrated in FIGS. 4A, 4B and 5 A, 5 B which will be now described with the corresponding parameters.

[0045] In FIG. 4A the dialogue for sending short messages from the SCP to the SMSC is shown. First, a MAP-Open-Request is sent from the SCP. This service is used to establish a dialogue between two MAP service users and to send the short message for example to the SMSC. This service is a confirmed service. Service parameters therefor are e.g.:

[0046] application context name for identifying the type of application context; destination address and destination reference for identifying the international mobile subscriber identity IMSI;

[0047] originating address and originating reference which is in the case that the SCP sends the short message for example either the mobile subscriber international ISDN (MSISDN) number of the SCP or the network element number of the SCP;

[0048] result for indicating whether the service is accepted;

[0049] refuse reason for indicating why the service is not accepted, for example wrong MAP version, invalid destination or originating reference and the like; and

[0050] provider error for indicating a protocol type error such as service not supported, resource limitation, initiation of release no response and the like.

[0051] After the MAP-Open-Request is sent, the SCP sends a MAP-Forward-Short-Message by which user information are delivered to the mobile station. Also this service is a confirmed service. For example, the following parameters are used:

[0052] SM RP DA, which is a SMSC destination address. The format is an international ISDN address.

[0053] SM RP OA, which is the short message originating address. In the case, that the SCP is sending the short message it is the MSISDN number of the SCP. If the network has several SCPs each has to have its own MSISDN number.

[0054] SM RP UI, which includes several sub-parameters. Said sub-parameters will be described later.

[0055] user error, for example unidentified subscriber, system failure, short message delivery failure in mobile terminated or mobile originated short messages (e.g. protocol error or the like), unexpected data value and the like.

[0056] As mentioned above, the parameter SM RP UI comprises several sub-parameters. It has to be coded according to a commonly known SMS-Submit type. Examples of such sub-parameters are given herein below (abbreviation TP stands for transport protocol):

[0057] TP-Message-Type-Indicator;

[0058] TP-Status-Report: indicates whether a status report is requested or not;

[0059] TP-Destination-Address: indicating the address of the receiving mobile station;

[0060] TP-Protocol-Identifier: identifies, which protocol type is used, for example short message type, replace short message type, return call message (A short message type 0indicates that the mobile station has to acknowledge the receipt of the short message but may discard its contents. The Replace Short Message feature is optional for the mobile station and the SIM but if implemented it shall be performed as described here. For mobile terminated short messages, on receipt of a short message from the SMSC, the mobile station shall check to see if the associated protocol identifier contains a Replace Short Message Type code. If such a code is present, then the mobile station will check an associated SMSC address and originating address and replace any existing stored message having the same protocol identifier code, SMSC address and originating address with the new short message and other parameter values. If there is no message to be replaced, the MS shall store the message in the normal way. If a Replace Short Message Type code is not present then the MS will store the message in the normal way. On the other hand, in mobile originated short messages, the SMSC reacts similarly but only the address of the originating mobile station or any other source is checked.);

[0061] TP-Data-Coding-Scheme: provides alphabets and language-specific information and data coding class (for example, class 0: mobile station has to display short message immediately, used for prepaid; class 1: mobile station has to send an acknowledgement to the SMSC; class 2: mobile station has to ensure that the message has been transferred to the SMS data field of the SIM card, used for localized GSM service; class 3: similar to class 1);

[0062] TP-User-Data-Length;

[0063] TP-User-Data: coded for example for localized services in a Localized GSM System Interface Specification.

[0064] After the above described MAP-Forward-Short-Message in FIG. 4 A, the SCP sends a MAP-Delimiter-Request to the SMSC which is used for delivery of the short message to the mobile station. This service is unconfirmed.

[0065] The SMSC sends MAP-Open-Confirm and a MAP-Forward-Short-Message-Confirm messages to the SCP. By the latter the receipt of the short message is acknowledged. Further, a MAP-Close-Indication is sent to the SCP by which the MAP dialogue is closed. This service is also unconfirmed and includes for example a release method parameter by which it is indicated whether a normal release or a prearranged release method for the dialogue is used.

[0066] In FIG. 4B also a dialogue between the SCP and the SMSC is shown similar to that described with reference to FIG. 4A . However, in this case, the dialogue is initiated by the SMSC (MAP-Open-Request, MAP-Forward-Short-Message-Request, MAP-Delimiter-Request) and responded by the SCP (MAP-Open-Confirm, MAP-Forward-Short-Message-Confirm, MAP-Close-Indication). The above described parameters also valid in this case. The dialogue illustrated in FIG. 4B is for example used for sending the status report to the SCP, which will be described below.

[0067] When in step S 6 according to FIG. 2 a confirming of the short message is required, the SMSC has to send a status report to the SCP. Therefor, the SMSC has to query routing information, i.e. location information of the SCP. As mentioned above, there are two possibilities where the SMSC can request said routing information which are illustrated in FIGS. 5A and 5B . Sub-routines ‘sending short messages to SMSC’ and ‘sending status report as short messages to SCP’ correspond to the message charts illustrated in FIGS. 4A and 4B , respectively.

[0068] A first case is shown in FIG. 5A . Here, the routing information is requested from the home location register HLR. After the short message was sent from the SCP to the SMSC (see FIG. 4A ), the SMSC asks for location information of the SCP at the HLR by a Send-Routing-Info-For-SM-Request. By responding to said query the HLR gives the MSISDN (or MSC number) of the SCP as said location information to the SMSC. Said Send-Routing-Info-For-SM service includes several parameters which are similar to that of a commonly known MAP-Send-Routing-Info service. These parameters are for example:

[0069] MSISDN number of the SCP;

[0070] SM-RP-PRI, which indicates whether or not a delivery of the short message shall be attempted when the service center address is already contained in a Message Waiting File;

[0071] service center address of the SMSC;

[0072] MSC number, which is the MSISDN number of the SCP;

[0073] user error, such as unknown subscriber, system failure, data missing and the like;

[0074] provider error, such as a protocol type error, for example service not supported, resource limitation, initiation of release no response and the like.

[0075] In the above described case, the SCP acts like a mobile station and a mobile switching center MSC to the SMSC.

[0076] Another possibility for the SMSC to request the routing information of the SCP is shown in FIG. 5B . Here, the Send-Routing-Info-For-SM-Request is directed by the SMSC to the SCP itself. Therefore, the SCP has implemented the MAP-Send-Routing-Info-For-SM service, as mentioned above. In the response, the SCP includes the MSISDN number of the SCP. The location information for the subscriber (MSC number) is also the MSISDN number of the SCP. In this case, the SCP acts as mobile station, home location register and mobile switching center to the SMSC.

[0077] In both described cases, after receiving the routing information, the SMSC sends a status report using said routing information to the SCP according to the operation shown in FIG. 4B .

[0078] It is to be noted, that besides the parameters and sub-parameters described above which relate to the services used in MAP dialogue there are also further parameters and sub-parameters not mentioned but present and known to a person skilled in the art.

[0079] A procedure for checking a MAP type used by the SCP is now described with reference to FIG. 3 .

[0080] The MAP type, indicated for example by a version number, is important to know, since sending of the status report is only possible when the SMSC supports at least version 2. Therefore, when the SCP requests a status report for confirming the outcome of the short message, it has to be ensured that the SMSC is able to send such a status report.

[0081] In FIG. 3 , when starting a MAP type determining procedure, first in step S 21 the MAP type (e.g. by the version number) used by the SCP is determined. If the MAP type used is supported by the SMSC (step S 22 ), i.e. at least version 2, the handling of the short message is performed as described above and a status report can be returned (step S 23 ). However, when it is determined that the MAP type used by the SCP is not supported by the SMSC, i.e. the SMSC only supports for example version 1, the dialogue is ended by the SMSC (step S 24 ). The MAP type supported (e.g. version 1) is announced to the SCP (step S 25 ). Thereafter, in step S 26 , the SCP opens a new dialogue with the MAP type supported by SMSC.

[0082] The message flow is similar to that illustrated in FIG. 4A . However, in the MAP-Forward-Short-Message-Confirm message from the SMSC a refuse reason is given relating to the fact that the application context is not supported. After MAP-Close-Indication the process is repeated accordingly beginning with a new MAP-Open-Request by the SCP.

[0083] It is to be noted that sending of short messages according to the invention is also possible when the SMSC does not support at least MAP type version 2. In such case, however, a status report can not be sent back to the SCP.

[0084] Now, reference is made to FIGS. 6 and 7 , in which the handling of error cases is illustrated. There are some error cases which have to been notified when MAP services are used. The MAP dialogue can be finished by a corresponding MAP-Abort service at any time after the MAP dialogue has been opened.

[0085] One possibility is that the MAP service user, i.e. the SCP, ends the MAP dialogue. In this case, there can be used a MAP-Close service as described above or a MAP-U-Abort service. The latter uses parameters such as follows:

[0086] user reason (resource limitation, resource unavailable, application procedure cancellation, procedure error);

[0087] diagnostic information which may give additional information for some values of he user reason parameter (for example in case of application procedure cancellation: handover cancellation, network path release, call release and the like).

[0088] Signaling shown in FIG. 6 for a user initiated connection end is similar to that described with reference to FIG. 4A .

[0089] The other possibility is that the MAP service provider, i.e. the SMSC, ends the MAP dialogue. In this case, there can be used a MAP-Close service as described above, or a MAP-P-Abort service, or a MAP-Notice service.

[0090] The MAP-P-Abort service enables the provider (SMSC) to abort the MAP dialogue. Parameters used therein are for example provider reason such as provider malfunction, version incompatibility, abnormal MAP dialogue and the like, and source which indicates the source of the problem (MAP, network service and the like).

[0091] Although not shown in FIG. 6 , the message flow for the case where the SMSC ends the MAP dialogue is similar to that of the case where the SCP ends the MAP dialogue. The difference is that the MAP-P-Abort message (instead of the MAP-U-Abort message shown in FIG. 6 ) is directed from the SMSC to the SCP.

[0092] In FIG. 7 , message flow in case of a MAP-Notice service is shown. The MAP-Notice service is used to notify the MAP service user, i.e. the SCP, the MAP dialogue problem. A parameter of this service is the problem diagnostic which indicates for example an abnormal event or a rejected response.

[0093] When using a short message transmission according to the present invention, the services should take care about charging when they are used.

[0094] Although in the above described only the transmission of a short message from a SCP to a mobile station via a SMSC by using a MAP interface is described, it is also possible to send the short messages directly to the mobile station for example via X.25, local area network LAN, transfer control protocol/internet protocol TCP/IP, and the like. Additionally, it is also possible to use unstructured supplementary service data instead of short messages.

[0095] The present invention proposes a method for transmitting specific information between a controlling network element and a terminal device via a service center in a communication network, said method comprising the steps of transmitting user data and said specific information between said network element and said service center via a first communication connection by using an interworking functionality; and forwarding at least said specific information from said service center to said terminal device by using a gateway functionality. It is further possible to check whether a confirming for outgoing of said specific information to said terminal device is required. If such a confirming is required, routing information for said controlling network element are requested and received by said service center from a network element. The routing information are used for transmitting a status report from said service center to said controlling network element. Moreover, the present invention proposes a corresponding device and/or system.

[0096] It should be understood that the above description and accompanying figures are merely intended to illustrate the present invention by way of example only. The preferred embodiments of the present invention may thus vary within the scope of the attached claims.