WO2010075890A1

WO2010075890A1 - Handling of delivery reports for messages having a one-to-many or many-to-one relationship

Info

Publication number: WO2010075890A1
Application number: PCT/EP2008/068360
Authority: WO
Inventors: Jin Zhang; Robert Kamphuis
Original assignee: Nokia Siemens Networks Oy
Current assignee: Nokia Solutions and Networks Oy
Priority date: 2008-12-30
Filing date: 2008-12-30
Publication date: 2010-07-08
Anticipated expiration: 2011-06-30

Abstract

A method for receiving a message for which a result record is generated. One or more linked result records are generated, where a linked result record comprises a link to or from the result record of the received message. Information is updated from delivery reports relating to the delivery of linked messages generated on the basis of the received message and transmitted to one or more destination nodes to the result record of the received message and to its linked result records. The method provides a simple and conservative implementation for one-to-many and many-to-one relationship between individually addressed mobile originated and mobile terminated messages and their associated reports.

Description

HANDLING OF DELIVERY REPORTS FOR MESSAGES HAVING A ONE-TO MANY OR MANY-TO-ONE RELATIONSHIP

FIELD OF THE INVENTION

The exemplary and non-limiting embodiments of this invention relate generally to telecommunications and more specifically to delivery and process- ing of short messages.

BACKGROUND ART

The following description of background art may include insights, discoveries, understandings or disclosures, or associations together with disclosures not known to the relevant art prior to the present invention but pro- vided by the invention. Some such contributions of the invention may be specifically pointed out below, whereas other such contributions of the invention will be apparent from their context.

Messaging Is generally used in telecommunications to refer to a set of features that let a user to create, store, send, receive, and manage different types of messages, for example, text messages, multimedia messages, e-mail messages, paging messages and fax messages. Messaging covers applications which are typically based on store and forward, store and retrieve, or store and push functions, and do not necessarily require real-time transport capabilities. Some messages are transferred unacknowledged, but outcome of a delivery of a message may also be recorded and returned to the sender of the message in a result record. Such result records are in several use cases very valuable; not only for the confirmation they provide to the person that sent the message but also for further applications and billing purposes.

Typically result records are created in one-to-one relationship, i.e. one result record is created for each transferred message. For example, a short message refers to a message of limited length, which may be sent between mobile stations, e-mail systems, computers, and voice frequency phones that support a short message service (SMS). The short message service is a telecommunication service for sending and receiving text messages, and it was initially defined in the standards for Global System for Mobile Communications (GSM). Today short message service is available on most digital cellular telephone networks and also in some paging systems.

SMS is a store-and-forward messaging technology that operates in near-real-time mode. The Short Message Service is realised by the use of the Mobile Application Part (MAP) of the SS#7 protocol, with Short Message pro- tocol elements being transported across the network as fields within the MAP messages. These MAP messages may be transported using traditional time- division multiplexing based signalling, or over IP using SIGTRAN and an appropriate adaptation layer. In short message delivery, a Protocol Data Unit (PDU) containing the text message is passed to a Service Centre (SC) for storing, and subsequent forwarding to the destination address. In the case of successful delivery, the delivered text message will be removed from SC and, if requested, a delivery report is sent to the originator of the text message. If the delivery fails, SC invokes a retry procedure to periodically make further attempts at delivery. In addition, SC may register with a home subscriber register of a recipient to receive a notification when the recipient becomes available for short message delivery in the future.

The conventional mobile originated and mobile terminated delivery mechanisms in SC create a one-to-one relationship where each short message arriving from an originating address to SC results in one short message to a destination address, and the outcome is uniquely linked to the one short message and to the one originating address. Some recent service ideas have created a need for a more flexible one-to-many and, on the other hand, many-to-one relations between the original and delivered short messages and their associated status reports. However, presently there are no applicable mechanisms to enable such variations. In many cases this leads to overly complicated technical implementations, or sub-optimal end-user experiences. In some conventional configurations, the state and relationship between multiplied messages and their associated status reports are stored, processed and managed in appSication level. This, however, significantly increases the storage and management procedures required in the appSication, and thereby makes application implementations easily too heavy and expensive for commercial use. in some professional systems, one-to-many relationship of messages and their associated acknowledgements are enabled by use of a group subscriber identity. When the originator addresses a short message to such group subscriber identity, the short message is forwarded to any subscriber who is presently a member of that particular group and acknowledgements in that group may be returned individually. This mechanism, however, requires that one subscriber can, at the same time, be referred to by an individual subscriber identity and by a group subscriber identity. Such mechanism is typically not supported in most public telecommunications systems.

SUMMARY

Various aspects of the invention comprise a method, an apparatus, and a computer program product as defined in the independent claims. Further embodiments of the invention are disclosed in the dependent claims. An aspect of the invention relates to a method that comprises receiving a message, and generating a result record for the received message, generating one or more linked result records, a linked result record comprising a link to or from the result record of the received message, and updating information from delivery reports to the result record of the received message and to its linked result records.

A further aspect of the invention is an apparatus that is configured to perform functionality according to any embodiment of the invention.

An aspect of the invention is a program product containing an executable code configured to perform a method according to any embodiment of the invention when executed in a computing device.

Although the various aspects, embodiments and features of the invention are recited independently, it should be appreciated that all combinations of them are possible and within the scope of the present invention as claimed. The aspects, embodiments and features illustrate a simple and conservative implementation for one-to-many and many-to-one relationship between individually addressed mobile originated and mobile terminated messages and their associated reports. A number of other positive consequences from the proposed mechanism are discussed in more detail with the detailed description of the embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

In the following the invention will be described in greater detail by means of exemplary embodiments with reference to the attached drawings, in which

Figure 1 shows a simplified block diagram illustrating elements used for the short message transfer in the exemplary system architecture. Figure 2 shows a simplified block diagram illustrating a typical example of a situation where there is a need for more variable report operations;

Figure 3 shows a simplified block diagram illustrating another use case with a similar problem;

Figure 4 shows a simplified block diagram illustrating some basic elements of an exemplary result record in the use case of Figure 3;

Figure 5 shows a simplified block diagram illustrating linked operations of the exemplary result records of Figure 4;

Figure 6 shows a simplified block diagram illustrating an exemplary combination of result records generated in SMS-SC in the use case of Figure 3;

Figure 7 shows a simplified block diagram illustrating linked operations of the exemplary result records of Figure 6;

Figure 8 shows a simplified block diagram illustrating a further use case; Figure 9 shows a simplified block diagram illustrating some basic elements of an exemplary result record in the use case of Figure 8;

Figure 10 shows a simplified block diagram illustrating linked operations of the exemplary result records of Figure 9;

Figure 11 shows a simplified flow chart illustrating an exemplary procedure implemented in a SMS-SC node in the use case of Figure 8; and

Figure 12 shows a simplified block diagram illustrating a block diagram of an exemplary apparatus configured to implement the embodiments of Figures 1 to 11.

DETAILED DESCRIPTION OF SOME EMBODIMENTS

Exemplary embodiments of the present invention will now be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the invention are shown. Indeed, the invention may be embodied in many different forms and should not be con- strued as limited to the embodiments set forth herein; rather, these embodi- ments are provided so that this disclosure will satisfy applicable legal requirements. Although the specification may refer to "an", "one", or "some" embodiments) in several locations, this does not necessarily mean that each such reference is to the same embodiment(s), or that the feature only applies to a single embodiment. Single features of different embodiments may also be combined to provide other embodiments.

The present invention is applicable to any node for any communication system or any combination of different communication systems that support a messaging service. The communication system may be a fixed commu- nication system or a wireless communication system or a communication system utilizing both fixed networks and wireless networks. The messaging service may apply to different types of messages, for example, text messages, multimedia messages, e-mail messages, paging messages and fax messages. The protocols and specifications of communication systems, servers and user terminals, especially in wireless communication, develop rapidly. Such development may require additional changes to an embodiment. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment.

As an example, short message service as specified in the 3rd Gen- eration Partnership Project (3GPP) specifications 3GPP TS 23.040 V8.0.0 (2007-12) "Technical realization of the Short Message Service", 3GPP TR 23.840 V7.1.0 (2007-03) "Study into routeing of MT-SMs via the HPLMN", and 3GPP TS 24.011 V7.0.0 (2007-06) " Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface" is applied in the present em- bodiment. It should be noted, however, that the scope of protection is not limited to the terms and definitions of the referred technology.

The Short Message Service (SMS) provides means of sending messages of limited size to and from mobile user terminals. The referred 3GPP specifications relate to a system applying Global System for Mobile Communications (GSM) or Universal Mobile Telecommunications Systems (UMTS). The provision of SMS makes use of a specific network element, a Service Centre (SC), which acts as a store and forward centre for short messages. Figure 1 shows a simplified block diagram illustrating elements used for the short message transfer in an exemplary system architecture. In the present embodiment, transfer of short messages to and from mobile stations is disclosed in more detail. It is noted that other types of short message entities, for example fixed and portable user terminals may be applied without deviating from the scope of protection.

The communications system comprises a mobile station MS 100 that represents here a mobile device. Together with the software, applications, and content that are directly related to it, the device functions within and is supported by mobile infrastructure of the applied communications network. For short message service support the mobile station is configured to communicate via the communications system with a short message service centre SMS-SC 101 and exchange short message transfer protocol data units with it. Mobile station 100 of the embodied communications system can be a simplified terminal for voice communication and short messaging or a multifunctional terminal for diverse services. In the latter case the terminal acts as a service platform and supports loading and execution of various functions related to the services. The mobile station 100 typically comprises mobile equipment and a subscriber identity module. The subscriber identity module is typically a smart card, often a detachably connected identification card, that holds the subscriber identity, performs authentication algorithms, and stores authentication and encryption keys and other subscription information that is needed at the mobile station. The mobile equipment may be any equipment capable of communicating in a mobile communication system or a combination of several pieces of equipment, for instance a multimedia computer to which a phone card has been connected to provide a mobile connection. In this exemplary context, the mobile station 100 thus refers to an entity formed by the subscriber identity module and the actual mobile equipment. According to the specifications, the Short Message Service comprises two basic services, SM MT (Short Message Mobile Terminated) and SM MO (Short Message Mobile Originated). SM MT denotes the capability of the GSM/UMTS system to transfer a short message submitted from the SC to one MS, and to provide information about the delivery of the short message either by a delivery report or a failure report with a specific mechanism for later delivery. SM MO denotes the capability of the communications system to transfer a short message submitted by the MS to a short message entity via SC, and to provide information about the delivery of the short message either by a delivery report or a failure report. In SM MO, a short message is delivered from the mobile station MS

100 to the short message service centre SMS-SC 101. Typically the subscriber inputs the message and a corresponding command through the user interface of the mobile station MS 100 that sends the text message over the air interface to the Mobϋe-services Switching Centre (MSC) or Serving GPRS Support Node (SGSN) 102. MS 100 retains the responsibility of the message until a report for the transmitted message arrives from the network; or a predefined timer expires. In case the element is MSC, it retrieves from a visitor location register VLR 103 the mobile subscriber international ISDN number (MSISDN) of the MS. If the retrieval is successful, MSC transfers the short message to an Interworking MSC For Short Message Service SMS-IWMSC 104. In case the element is SGSN, VLR 103 does not need to be consulted for MSISDN.

When SMS-!WMSC 104 receives a short message from the MSC/SGSN 102, it may interrogate the HLR of the recipient and retrieve the recipient's IMS! in order to check for the existence of an SMS Interworking agreement before establishing a Sink with the addressed SMS-SC 101. If the SMS Interworking agreement exists, SMS-IWMSC 104 establishes a Sink with SMS-SC 101 and transfers the short message to it.

When SMS-SC 101 receives the message, it stores it and returns a report on receipt to the network acknowledging the reception. SMS-IWMSC 104 relays a received report to MSC/SGSN 102. If a report is not received from the SMS-SC 101 before a preset timer expires, SMS-IWMSC 104 returns error information to MSC/SGSN 102 in a failure report. MSC/SGSN 102 relays the report (success or failure) to MS 100.

In SM MT, the short message is stored in SMS-SC 101 and delivered to MS 100. At a defined time, SMS-SC 101 transmits the message to Gateway MSC For Short Message Service (SMS-GMSC) 105, towards the receiving MS 100. SMS-SC 101 typically retains the responsibility of the message until a report for the transmitted message has been received from MS, or until a predefined validity period expires. SMS-GMSC 105 interrogates home location register (HLR) 106 of the receiving subscriber for routing information, and transfers the short message to the MSC/SGSN 102 using the routing information obtained from the HLR 106. In case of MSC, reception of the short message causes the MSC to retrieve from VLR 103 location area address of the receiving subscriber. If the retrieval is successful, MSC transfers the short message to MS 100 that acknowledges the reception with a delivery report. In case of SGSN, VLR 103 does not need to be consulted.

SMS Router (SMSR) 107 is an optional entity, and is essentially used only in the MT case. It has been included in the configuration due to issues of misusage (e.g. fraud issues of SMS faking and distribution of junk mail), and new regulatory requirements that public mobile networks must meet (e.g. Number Portability and Lawful Interception).

Conventionally, when MSC/SGSN 102 receives a confirmation that MS has received the message, it relays the positive confirmation in a delivery report to the SMS-GMSC 105. Otherwise it returns appropriate error information to the SMS-GMSC 105 in a failure report. SMS-GMSC 105 then creates and sends a corresponding successor failure report to SMS-SC 101. The relationship between a message and its associated delivery report is one-to-one such that each short message generates a unique result-entry and thus provides one status report to one destination. However, some recent service ideas have created a need for a more flexible one-to-many and many-to-one rela- tions between short messages and their associated status reports.

Figure 2 shows a simplified block diagram illustrating a typical example of a situation where there is a need for more variable report operations. The example is a so-called multipIe-SIM delivery service. SIM refers here to a subscriber identity module and represents means for identifying a communica- tion node that has a unique subscription. Elements A, B, C, and D thus denote communication nodes with different subscriber identities. A node with subscriber identity A (hereinafter referred to as A) sends a short message SMS1 to a node with subscriber identity B (referred to as B). The subscriber information retrieved during SM MT to subscriber B indicates that he wants this single SMS 1 to be forwarded to two other nodes, one with subscriber identity C (referred as C) and one with subscriber identity D (referred as D).

In order to enable tracking the success or failure of the delivery in SM MT, SMS1 needs to be multiplied into two unique short messages SMS1A and SMS1B, typically carrying the same user data. The division of SMS1 to SMS1 A and SMS1 B is often in the interest of the subscriber B, so optimally the originator A would not need to be involved at all with the operation. This means that A should get one status report on the delivery outcome for SMS1 , but this delivery outcome should be logically linked to the delivery outcomes of SMS1A and SMS1 B. The choice when to deliver the status report to A preferably should follow defined service logic. For example, A may need to be provided with the delivery report when B has received the short message, when both nodes C and D have received the short message, or when any one (or more) of the nodes C or D has received the short message. However, conventional SMS-SCs are not able to appropriately deal with status reports to implement such variable service logics. According to the conventional logic, the derivatives SMS1A and

SMS1 B of SMS1 would be treated as different short messages with their own result records. Depending on whether the result record would associate to the original sender A or not, A would either get no delivery report or get two reports for the original SMS1. In both cases the user experience of A would change due to the multiplication. If the information on the originator of the parent short message SMS 1 is carried as such to the result records of the derivatives SMS1A and SMS1 B, A will receive a delivery report for each of the delivered message SMS1A and SMS1 B. If the information on the originator of the parent short message SMS1 is not carried to the result records of the derivatives SMS1A and SMS1 B, A will not receive any delivery record for SMS1. Neither of these scenarios is actually acceptable. St is expected that B does not wish to disclose the identity or even the number of his other nodes C, D to A, so B would not subscribe a service that would provide this information in the form of delivery reports. On the other hand, many users of short message service pre- fer to use, or their operations are even depending on status information on their transmitted short messages. Without appropriate delivery reports the users, or their terminal applications, may remain in some kind of pending state, even if one or more copies of their short message had already reached the destination subscriber. An alternative approach in view of the conventional solution would be to select one of the derived short messages SMS1A as the traced short message. As soon as a delivery report from that derived short message SMS1A was received, a delivery report would be transmitted to A. This mechanism would provide A with same user experience, but naturally could not be relied on. For example, if SMS1 B is delivered and SMS1A not, subscriber B has received the user information but A would not get positive status report for SMS1. It is not likely that subscribers would accept a service where status reports do not correctly show the delivery outcome.

Figure 3 illustrates another use case with a similar problem. For optimal performance of some services, one would actually need to notify two or more separate parties of the delivery outcome of one short message. A typical example is a case where a short message SMS1 from A to B is first redirected to an application APP for additional procedures, for example for advertisement tagging. When the application APP ends the tagging it re-submits the short message SMS1 + with the additional advertisement to B. For this new compSe- mented short message SMS1+, one would actually need to trigger two status reports, SR1 back to the original subscriber A to inform the outcome of the short message delivery, and SR2 back to itself to inform the outcome of the advertisement delivery. As the status-report is currently linked one-to-one to the transmitted short message this is not, however, possible; the Advertise- ment tagging application needs special business logic to achieve the desired effect.

Application protocols for the redirection mechanism comprise, for example, a short message peer-to-peer protocol (SMPP) and a Computer Interface to Message Distribution (CIMD), which are supported in a number of different SMS-SC implementations. However, in such application based operations an advertisement gateway element needs to receive the status report on the complemented short message SMS1+ and needs to store extra information locally and create the additional status to the original sender A. This requires more complicated stateful processing on the Advertisement gateway part as it needs to maintain the link between the original short message it has received and the resulting status report from the advert-tagged new short message it has created. This clearly complicates the design and limits the scalability of such an advertisement-tagging implementation.

In the present embodiments these disadvantages are avoided by use of linked result records that are stored in SMS-SC and comprise a link to or from the result record of the received short message. These linked result records are used to establish a desired multiplied relationship between status reports in the short message receiving side and delivery reports in the transmitting side. Figure 4 illustrates some basic elements of a result record applicable to the use case of Figure 2, and implemented in the exemplary system con- figuration of Figure 1. The Short Message Relay Layer (SM-RL) provides a service to the Short Message Transfer Layer (SM-TL) and the protocol element for transferring Transfer Protocol Data Units (TPDU) from MS to SC is RP-MO- DATA. The TDPU carrying the short message to SMS-SC is SMS-SUBMIT PDU. SMS-SC receives the short message and stores it at least until a report on delivery has been received or the validity period of the short message expires. The short message service PDUs comprise the user data of the short message and a number of parameters to control the peer entity operations made upon SMSl The elements stored by SMS-SC and the format of the re- cord is not specified, so they typically vary according to the implementation. Hereinafter the term short message is used to refer to a combination of user data and any information element, like primitives and parameters that is included in the PDUs of the short message transmission of the user data. A result record refers to a defined selection of these elements, and possibly some other information that is recorded and stored in SMS-SC in respect of one short message user data block for reporting and possible retransmission purposes. A result record may comprise all information elements from the short message or only part of it.

Figures 4 and 5 illustrate an exemplary combination of result re- cords generated in SMS-SC in the case where the one short message from A to B is multiplied into two short messages to C and D. It is noted that Figure 4 illustrates only result record elements necessary for understanding the proposed embodiment. SMS-SC implementations may apply result records that comprise a variety of elements that are not relevant for the embodiment and therefore not discussed here. When the short message SMS1 arrives to SMS- SC, it detects whether the short message associates to only one destination node, or whether there are more destination nodes where the same user data should be delivered. The detection may be applied in several ways without deviating from the scope of protection. In this example, the request to multiply incoming short messages is recorded into the subscriber database of B. As illustrated in Figure 1 , at delivery of SMS-SUBMIT the subscriber database of the recipient is interrogated. During that communication SMS-SC may also retrieve relevant subscriber data and on the basis of that subscriber data determine the request of multiplication and the addresses of the other nodes C and D.

Having detected the need for multiplication of SMS1 , SMS-SC gen- erates new linked short messages SMS1A and SMS1 B and a combination of result records P, C1 and C2 illustrated in Figures 4 and 5. As shown in Figure 4, each of the result records comprise an identification field ID-P, ID-C1 and ID-C2 that represents means for linking the generated result records to each other. This explicit linking may be varied or replaced by implicit linking without deviating from the scope of protection. Each of the result records also comprises a classification flag that represents means for marking the result record as a parent result record (PF) or a child result record (CF). A parent result record refers to a result record that comprises information on an address where information from the result record is to be forwarded to. Field INFO-A represents here means to identify an address of a report node to which a status report on delivery of the submitted short message SMS1 is to be forwarded. A child result record is ϋnked to a parent result record, not directly to any report node. Field INFO-P thus represents here means to identify the parent result record P, to which the child result records are linked.

Each of the result records comprise a result field RES-P, RES-C1 , RES-C2 that represents means for storing the outcome of a short message. The parent result record P stores the outcome of the original short message SMS1 and the child result records C1 , C2 store the outcome of the multiplied short messages SMS1 A, SMS1 B.

The child result records C1 and C2 comprise fields INFO-SMS1A and INFO-SMS1 B that represent means for associating a received delivery report to a short message transmitted from SMS-SC to a destination node. The Short Message Identifier (SMI) is typically not carried between entities and therefore a given message may have different SMIs at the MS and SC sides. In this embodiment, SMS-SC applies a globally unique identity to identify a transmitted short message SMS1A and associate it via field INFO-SMS1A to the corresponding child record C1 , and correspondingly SMS1 B via field INFO- SMS1 B to the corresponding child record C2. As an example of such identity, a combination of a timβstamp and the destination address is used. Other mechanisms for associating a delivery report to a transmitted message may be applied without deviating from the scope of protection.

The parent result record P comprises a field COUNT1 that represents means for adjusting the delivery outcome of the multiplied messages before a status report to the address INFO-A is triggered. In this embodiment the means are implemented by cumulatively collecting the number of positive update indications from the linked child result records C1 and C2 to RES-P field and at each update comparing the cumulated number to a defined trigger value stored in COUNT! When the trigger value is achieved or exceeded, a status report is transmitted from SMS-SC. The linked operations of result records of Figure 4 are described in more detail in Figure 5. Reception of SMS1 in SMS-SC triggers generation of short messages SMS1A and SMS1 B that are derived from the original short message SMS1. SMS1 A and SMS1 B typically comprise the same user data as the original short message SMS1 and the same parameters that characterize the SMSl Such parameters comprise, for example, the validity periods, data coding schemes, user data header indications, and the like. The combination of the timestamp and the destination address parameters that identify the transmitted short message are, however, different from the parameter of the original short message so that when delivery report DR-SMS1A for SMS1A and DR-SMS1 B for SMS1 B arrive, they are associated to respective child result records C1 and C2 instead of the parent result record P.

When a delivery report DR-SMS1A, DR-SMS1 B arrives, SMS-SC is configured to update the outcome to the associated result record, in this case to RES-C1 , RES-C2 fields of the child result records C1 , C2, respectively. Up- date in a result record triggers SMS-SC also to check whether the updated result record is linked to another result record and/or a report node. In this example, SMS-SC first detects a delivery report DR-SMS1A for SMS1A, or DR- SMS1 B for SMS1 B, associates it to C1 or C2, and updates the outcome to RES-C1 field in C1 , or RES-C2 field in C2. SMS-SC also detects a link via INFO-P field to parent result record P and updates the result of the delivery record to RES-P field in it. In this example, the update comprises incrementing the value of RES-P if the delivery report indicates that the respective message was successfully received. After this update, SMS-SC compares the value of RES-P to value of COUNT! It may be seen that by setting the COUNT1 value, different type of responses may be made. For example, let us assume the trigger condition is configured to initiate delivery of positive status report when RES-P > COUNT1.

- If COUNT1-0, a positive status report on SMS 1 is provided right after either of the multiplied short messages SMS1A or SMS1B is successfully deliv- ered.

- If COUNT1=1 , a positive status report on SMS1 is provided only after both of the multiplied short messages SMS1A and SMS1 B are successfully delivered.

It is noted that the multiplication is illustrated for a simple configuration of two multiplication endpoints C and D. In case there are more muitipfica- tion endpoints, the amount of possible variations increases. For example, if there are three endpoints C, D, E, and the multiplied short messages SMS1A, SMS1 B and SMS1 C, correspondingly, the variations via COUNT1 would enable the following options:

- If COUNTI=O, a positive status report on SMS1 is provided right after any of the multiplied short messages SMS1A, SMS1 B or SMS1 C is successfully delivered.

- Sf COUNTI =I , a positive status report on SMS1 is provided after any two of the multiplied short messages SMS1A, SMS1 B or SMS1C are successfully delivered. - If COUNT1 =2, a positive status report on SMS1 is provided only after all multiplied short messages SMS1A, SMS1 B and SMS1 C are successfully delivered.

As shown above, the use of the combination of linked result records enables multiplication of a short message without generating unnecessary or unwanted reports to the originator of the short message. !t further provides a simple mechanism to adjust the relationship between the outcomes of the multiplied messages and the outcome of the original message to appropriately reflect the delivery status in various use cases.

Figures 6 and 7 illustrate an exemplary combination of result re- cords generated in SMS-SC in the use case of Figure 3, again implemented in the exemplary system configuration of Figure 1. In the use case of Figure 3, the original short message SMS1 is complemented in an application APP with additional information, and the complemented short message SMS1+ is delivered to SMS-SC. For correct operation of the associated application service, both the originating node A and the application gateway APP should receive a status report for the delivery of the user information in SMS1/SMS1+.

As shown in Figure 6, the parent result record P comprises the fields ID-P, PF, INFO-A, COUNT1 , and RES-P, already described in connection with Figure 4. In addition, the parent result record P comprises also a field I N FO-SMS 1+ that comprises information for associating a received delivery report on with a transmitted short message. As shown in Figure 7, in this em- bocliment, the short message is delivered to only one destination node, so SMS-SC transmits SMS 1+ and receives a delivery report DR-SMS 1 +. The delivery report associates now to the parent result record P and the outcome is updated to RES-P field in P. When the short message SMS 1+ arrives to SMS-SC, it is configured to detect whether there is a request for provision of additional status reports for the same message. The request may be indicated, for example by a predefined bit or by some other adjustment in one of the fields of SMPP or CIMD PDUs. Other methods for indications, obvious for persons skilled in the art, may be applied without deviating from the scope of protection. For example, SMS-SC may be configured to identify defined gateways (e.g. advertisement gateways) and provide additional reports for all short messages arriving from such gateways. When such a request has been detected, SMS-SC determines the addresses of these additional report nodes and generates, for each of the additional report nodes, a secondary result record S.

The secondary result record S comprises the identification field ID- S, the result field RES-S and the parent flag PF, as described in Figure 4. In addition, the secondary result record S comprises a field INFO-APP that comprises the address of the additional report node, to which status report on the short message SMS1+ is to be provided. In the example of Figure 6, the secondary result record S associates to the application APP and the parent result record associates to the source A of the original short message SMS1. This association between report nodes and primary and secondary parent records may be changed without deviating from the scope of protection. As shown in Figure 7, when SC receives the delivery report DR-

SMS1 +, and updates the outcome to RES-P field in P, it also detects a link via ID-S to the secondary result record and updates the result also to the RES-S field in S. Update in the RES-P field of P triggers delivery of the status report SR-A on SMS1 to A, and the update in the RES-S field in S triggers delivery of the status report SR-APP on SMS 1 + to APP.

Use of linked result records as shown above provides a simple and straightforward mechanism to provide additional status reports for individual messages. The solution re-uses effectively existing storage mechanisms and can therefore in a straightforward manner be implemented without major changes in the neither storage implementations nor business logic of the delivered applications. This ensures speedy development and promotes introduc- tion of services that have this need for multiplication, either in the report side or in the delivery side.

As a further advantage, the described record configurations enable also simultaneous multiplication in both directions. Figure 8 illustrates a further use case where elements of the earlier embodiments are applied together. Accordingly, additional details for the elements and operations may be referred from the associated Figure 4 to 7. In this case, a short message SMS1 from A to B is first redirected to an application APP for additional procedures and the short message SMS1+ with the additional advertisement is forwarded to B. However, the subscriber profile of B indicates that B wants short messages addressed to him to be forwarded to two other nodes, C and D.

When SMS1 + arrives to SMS-SC, it detects that B has requested delivery of the short message to additional destination nodes and that SM-AL PDU of SMS1+ comprises an information element that requests delivery of status report to an additional report node APP. SMS-SC generates derived short messages SMS1A+ and SMS1 B+ and their associated result records. Figure 9 illustrates a combination of result records that SMS-SC generates in this case. The parent result record P is like the parent result record in the earlier embodiment, and associates to the submitted short message SMS1+. The chiid records C1 and C2 are like the child result records of Figure 4, but associate to the delivered short messages SMS1A+ and SMS1 B+. The secondary result record S is like the secondary record S in Figure 6.

As shown in Figure 10, SMS-SC transmits the short messages SMS1A+ and SMS1 B+ and receives delivery reports DR-SMS1A+ and DR- SMS1 B+ on the delivered messages. The delivery reports are associated to respective child records C1 and C2, and the results are updated to their result fields RES-C1 and RES-C2, as described in Figure 4. SMS-SC also detects the links via INFO-P field to the parent result record P, and updates the result (here: increments successful responses) to RES-P field of P, as well. As de- scribed in Figure 4, SMS-SC compares the incremented value of RES-P field with the defined value of COUNT1 field and triggers generation and transmission of status report SR-A to address in INFO-A field of P, when the condition established between the RES-P field and COUNT1 is fulfilled. Via the ID-S field SMS-SC also detects the link between the parent result record P and the secondary result record S, and updates the result to the RES-S field of S. Update to RES-S triggers generation and transmission of status report SR-APP to the address in INFO-APP field.

It is noted that the embodiments show some examples from the use of linked result records. In many systems, results may be indicated implicitly or explicitly. For example, in the embodied 3GPP system, negative result may mean an explicit error code in the delivery report or end of validity period. In some examples the triggering logic a!so applies the number of positive results that indicate successful transmission of short messages. The proposed solution is not limited to the shown examples in SMS, but is applicable to a variety of explicit and implicit report mechanisms of various messaging services and to positive and negative result indications. Due to the streamlined linking configuration, the multiplication schemes for both reporting and message transmission can be easily adjusted to match the prevailing service offering.

The exemplary embodiments of this invention provide a method that comprises prior art steps, and also steps for generating one or more linked result records, a linked result record comprising a link to or from the result record of the received message; and updating information from delivery reports to the result record of the received message and to its linked result records. Figure 11 illustrates an exemplary procedure implemented in a SMS-SC node in the use case of Figure 8. Accordingly, additional details for the steps may be referred from Figures 9 and 10. The procedure begins in a situation where SMS-SC is switched on and standby for new incoming short messages. When a new short message MO SMS1 ÷ is received (step 110), SMS-SC checks (step 112) whether the short message is to be delivered to one or more destination nodes. In this embodiment the check is implemented by determin- ing whether the user profile of the recipient user includes an instruction to multiply the message to two more destination nodes DP. If the answer in step 112 is Yes, SMS-SC generates (step 114) derived short messages SMS1A+ and SMS1 B+, and creates their associated child result records C1 , C2, and the parent result record P (step 116). If the answer in step 112 is No, SMS-SC moves directly to step 118 to check whether the status of the delivery of the short message is to be reported to one or more report nodes RP. If the answer in step 118 is Yes, SMS-SC creates (step 120) a secondary result record S, as described in Figure 9 and sends (step 122) the derived short messages SMS1A+ and SMS1 B+. If the answer in step 118 is No, SMS-SC moves di- rectly to step 124 to check whether a delivery record DR on one or more of the generated messages is received. If the answer in step 126 is Yes, SMS-SC updates (132) delivery outcome from each received delivery outcome to the associated child result record C1 , C2. In this example, the outcome may be positive or explicitly negative with an error code. If the answer in step 126 is No, SMS-SC checks (128) whether the validity period of the transmitted short messages has expired. In this embodiment the validity period of the original short message and of the transmitted short messages is the same. If the answer in step 128 is No, SMS-SC returns to step 124 to check for more delivery reports DR. If the answer in step 128 is Yes, SMS SMS-SC determines (step 130) that the delivery of the expired message has failed and updates (step 132) this information to the associated child result record C1 , C2. An update in the child result record C1 , C2 that comprises a link causes an update (step 134) to the linked parent result record P. When the parent result record P is updated, SMS-SC checks (step 136) whether defined fields COUNT1 , RES-P fulfil a defined trigger condition TRIG. If the answer in step 136 is No, SMS-SC returns to step 126 to check for new delivery reports DR. If the answer in step 136 is Yes, SMS-SC updates (step 138) the secondary result record S, and sends a status report to detected report nodes, in this example to the originating subscriber A (step 140) and to the application node APP (step 142).

It is noted that the validity period of the original short message and of the transmitted short messages need not be the same. The service logic may be further enhanced by, for example, applying for derived short messages a shorter validity period than for the original short message. In case the delivery of derived short messages fails within their shorter validity period, SC may be configured to attempt delivery to the original destination address. The steps, signaling messages and related functions described above in Figure 11 are in no absolute chronological order, and some of the steps may be performed simultaneously or in an order differing from the given one. The procedure is simplified, so other functions can also be executed between the steps/points or within the steps/points and other signaling messages sent between the illus- trated messages. Some of the steps/points or part of the steps/points can also be left out or replaced by a corresponding step/point or part of the step/point. The SMS-SC operations illustrate a procedure that may be implemented in any one or more physical or logical entities that manage MO and MT short messages. The method enables adjustment of the number of messages and related reports substantially within one logical entity, which means that opera- tions necessary to achieve the desired adjustment may be implemented without substantial changes to existing interfaces and installed system entities.

The exemplary embodiments of this invention also provide an apparatus that comprises prior art means, and also means for generating one or more linked result records, a linked result record comprising a link to or from the result record of the received short message; and updating information from delivery reports to the result record of the received short message and to its linked result records. Figure 12 illustrates a block diagram of an exemplary apparatus configured to implement the embodiments of Figures 1 to 11. In general, the various embodiments may be implemented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects may be implemented in hardware, while some other aspects may be implemented in firmware or software, which may be executed by a controller, microprocessor or other computing device. Software routines, which are also called as program products, are articles of manufacture and can be stored in any apparatus-readable data storage medium and they include program instructions to perform particular tasks.

The apparatus comprises an interface unit 200 with at least one input unit for inputting data to the internal processes of the apparatus and at least one output unit for outputting data from the internal processes of the apparatus. In a network element apparatus the interface unit typically comprises plug-in units acting as a gateway for information delivered to its external connection points and for information fed to the lines connected to its external connection points. The interface unit of the apparatus may also comprise a user interface with a keypad, a touch screen, a microphone, and equals for inputting data and a screen, a touch screen, a loudspeaker, and equals for outputting data.

The interface unit 200 is electrically connected to a processor unit 202 for performing systematic execution of operations upon data. The proces- sor unit 202 is an element that essentially comprises one or more arithmetic logic units, a number of special registers and control circuits. Memory unit 204, data medium where computer-readable data or programs, or user data can be stored, is connected to the processor unit 202. The memory unit 204 typically comprises volatile or non-volatile memory, for example EEPROM, ROM, PROM, RAM, DRAM, SRAM, firmware, programmable logic, etc.

The interface unit 200, the processor unit 202, and the memory unit 204 are electrically interconnected for performing systematic execution of operations on the received and/or stored data according to the predefined, essentially programmed processes of the apparatus. These operations are described in more detail with Figures 1 to 11. The exemplary embodiments of this invention also provide a computer program product, readable by a computer and encoding a computer program of instructions for executing a computer process for controlling functions in the apparatus of Figure 12.

While various aspects of the invention may be illustrated and de- scribed as block diagrams, message flow diagrams, flow charts and logic flow diagrams, or using some other pictorial representation, it is well understood that the illustrated units, blocks, apparatus, system elements, procedures and methods may be implemented in, for example, hardware, software, firmware, special purpose circuits or logic, a computing device or some combination thereof. It will be obvious to a person skilled in the art that, as the technology advances, the inventive concept can be implemented in various ways. The invention and its embodiments are not limited to the examples described above but may vary within the scope of the claims.

Claims

1. A method, comprising: receiving a message; generating a result record for the received message, c h a r a c - terized by generating one or more linked result records, a linked result record comprising a link to or from the result record of the received message; updating information from delivery reports to the result record of the received message and to its linked result records.

2. A method according to claim ^characterized by detecting one or more destination nodes to which linked messages, generated on the basis of the received message, are to be transmitted; for each of the destination nodes, generating a linked message and an associated linked result record, the linked result record comprising a link to the result record of the received message.

3. A method according to claim 2, characterized by transmitting the linked messages; updating information from received delivery reports to associated linked result records; updating information from linked result records to the result record of the received message.

4. A method according to claim 1, 2, or 3, characterized by the result record of the received message comprising an indication of a report node; and the method further comprising providing a report on the delivery of the message to the report node.

5. A method according to claim 4, characterized by counting the number of updates to the result record of the received message; sending the result from delivery of the message to the report node in response to the number of updates totalling a predefined value.

6. A method according to any of claims 1 to 5, characterized by detecting one or more additional report nodes to which an additional report on the delivery of the message is to be provided; for each of the additional report nodes, generating a secondary re- suit record including information on the additional report node to which a report on delivery of the message is to be provided; including a link from the result record of the received message to the secondary result record; transmitting the message; updating information from a received delivery report on the message to the result record of the received message and to the linked secondary result record.

7. A method according claim 4, characterized by counting the number of updates to the result record of the received message; sending the update to the linked secondary result record in response to the number of updates totalling a predefined value.

8. An apparatus, comprising: an interface unit for receiving a message; a memory for storing a result record for the received message, characterized by a processor module connected to the interface unit and the memory and configured with instructions to generate one or more linked result records, a linked result record comprising a link to or from the result record of the received message; and update information from delivery reports to the result record of the received message and to its linked result records.

9. An apparatus according claim 8, characterized by the processor being further configured with instructions to detect one or more destination nodes to which linked messages, generated on the basis of the received message, are to be transmitted; for each of the destination nodes, generate a linked message and an associated linked result record, the linked result record comprising a link to the result record of the received message.

10. An apparatus according to claim 9, characterized by the processor being further configured with instructions to transmit the linked messages; update information from received delivery reports to associated linked result records; updating information from linked result records to the result record of the received message.

11. An apparatus according to daim 8, 9, or 10, characterized by the result record of the received message comprising an indication of a report node; and the processor being further configured with instructions to provide a report on the delivery of the message to the report node.

12. An apparatus according to claim 11, characterized by the processor being further configured with instructions to count the number of updates to the result record of the received message; send the result from delivery of the message to the report node in response to the number of updates totalling a predefined value.

13. An apparatus according to any of claims 8 to 12, characterized by the processor being further configured with instructions to detect one or more additional report nodes to which an additional report on the delivery of the message is to be provided; for each of the additional report nodes, generate a secondary result record including information on the additional report node to which a report on delivery of the message is to be provided; include a link from the result record of the received message to the secondary result record; transmit the message; update information from a received delivery report on the message to the result record of the received message and to the linked secondary result record.

14. An apparatus according claim 4, characterized by the processor being further configured with instructions to count the number of updates to the result record of the received message; send the update to the linked secondary result record in response to the number of updates totalling a predefined value.

15. A computer program comprising program code means adapted to perform any of steps of claims 1 to 7 when the program is run on a processor.