In today's world there are many different types of messaging services available both in the wired and wireless worlds. Some services are supported in both, others are only found in one. Each service has it's own individual characteristics, however in general messaging services are made of messages that require immediate delivery, and messages that do not require immediate delivery. This clause examines the architectural issues surrounding the delivery of these types of messages by looking at the current messaging services as mentioned in the 'Background' section.
Although the expectation of the user has moved towards the SMS service appearing to be real time, the fact of the matter remains that the SMS service is not a real time service since there is no communications association between the originator and the recipient. Therefore the message type that is used in this service is classed as 'Non-Immediate Messages'. However, the fact that the message is classed as 'Non-Immediate' does not preclude the fact that the delivery of the message may still appear to be 'real time' to the user.
From an architectural viewpoint the question is raised as to whether or not developments to the IMS are required in order to support this service.
With MMS there is no expectation from the user for the message to be delivered in 'real time'. Currently the expectation is similar to that of e-mail where the originator sends to message to a mailbox. Therefore, since there is no communications association between the originator and the recipient the messages can be classed as 'Non-Immediate Messages'. As with the SMS service this does not preclude the fact that the message could be delivered in what appears to be 'real time'.
As with SMS, the question has to be raised as to whether or not there are requirements to develop the IMS to be able to meet these requirements.
When using the Instant Message service, the user's expectation is that the communication between themselves and the recipient is 'real time'. To meet this expectation it is important to have a communication association between the originator and the recipient. The following are two examples of how this could be achieved:
In this scenario, an IMS session is set-up between the originator and the recipient. Each terminal has an Instant Message application capable of creating messages in a standardised way to ensure interoperability with other terminals that also have the same ability.
Although this scenario provides a simple solution, implementation of the service remains complicated and restrictive. For example, the service is being provided via the terminal, and not being provided by the operator. How will the operator charge for the service? Is the implementation efficient in providing such a service?
This would also mean that every service that makes use of 'Immediate Type' messaging would require the application to be built in or be able to download to the terminal as necessary. Because of these issues it is suggested that this type of solution is not considered for deploying services that utilise 'Instant Messaging' types.
In this scenario it is assumed that the Instant message can be conveyed over the IMS signalling path, this would require further study as to the maximum size of the message that can be transferred to enable the operator to provide a service that is perceived as real time.
It is noted that on some occasions users transfer attachments between each other, however the user's expectation is that these are not delivered in 'real time'. Therefore, attachments would not be considered as messages carried IMS signalling path. Instead it is suggested that a separate context is established for the transfer of such a file.
Using this scenario has a distinct advantage over the use of MMS in the case where the user is roaming. This is discussed as follows:
Consider the following scenario where User A, who is a UK registered user roaming in France is holding an Instant Messaging session with User B, who is a French registered user roaming in the UK.
In this scenario where User A sends User B a message irrespective of the solution used, IMS or MMS, the message trombones across the operator's roaming boarders three times. However the key difference is that within an IMS solution there is a communication association between the originator and the recipient, where as with the MMS solution the association is between the originator and the MMS server.
Now consider the scenario where during the message session User A wants to send User B a photo which is in the region of 500K.
In the case of the MMS deployment, the 500K file is sent from User A to MMS Server of User A positioned in the UK. From there the 500K file is forwarded to the MMS server of User B in France. The 500K file is then sent to or retrieved by User B in France. As can be seen the trombone effect is now a serious problem in terms of efficiency and cost.
If this scenario is now compared to the scenario where a separate session is created to transfer the attachment it can be seen that the 500K file only crosses the operator roaming boundary once. Clearly, a far more efficient solution.
Further study is required into the charging and billing issues but from early investigation this solution does provide the operator with various options.
The Chat service as noted in the previous section, is very similar to that of Instant Message type services where the expectation of the user is that an originated message reaches the recipients in what is perceived as 'real time'. Therefore it is important that there is a communication association between the originator and the recipients.
The main difference between the Chat Service and the Instant Message service is that in general Instant Messaging is between two users, whereas chat is normally between a group of people. However it is the fact that the user's expectation is 'real time' leads to the question as to whether or not an IMS signalling path could not be used.
As mentioned earlier Chat rooms can be split into two categories, Public and Private. However the deployment is very similar in both cases
An IMS signalling path may be used to carry the message to the Chat Server which distributes the message in a similar way to that of Instant Messaging. As with Instant Messaging, a majority of the message are short bursts of text, however it is important to consider attachments and how they will be dealt with. This is for further study.
This is similar to that of the MMS architecture. Email is not classed as real-time and therefore there is no requirement for the IMS to establish a real time connection between the device and the email server, irrespective of the email service provider.