SMS Email Inter-working

SMS to email and email to SMS conversion is a popular concept which is available as for the current condition. This was first developed as an application which is built on top of the SMSC. Any text message or email is sent to the application and application handled the logic thereafter.

But as with the increasing trend of use of this service it has come to a level where this service is included in the SMSC itself rather than using it in a seperate application. Including the service in the SMSC will provide some advantages rather than having it as an application. The time spent on

To start connection between SMSC and applicaiton

The connection handling, authorizing procedures

Complex acknowledgement processes

can be eliminated by integrating the service inside the SMSC.

There are some basic things that should be taken care in the process of providing a successful service.

1. Basic format

There should be basic format where users using this service must adhear to in order to perform successful conversion between sms and electronic mail. There would be two seperate formats for MO flow and MT flow

E.g.

MO - ]

MT - ]

In the above examples MO represents the text to email conversion whereas in MT it represents the email to text conversion

Some features like Carbon Copy wont be supported in this formats since it would restrict the capacity of the messages

Subject, real name of the sender, optional control flags and message concatenations would be treated as optional features.

Unlike in usual emails, name should be entered manually by the user.

]#[##]#

Subject of the email also should be inserted according to the format like in following examples

]() or ]###

Optinal controller flags are also available to use the features like email signatures, predefined texts etc. The important thing to remember is all the optional controller flags are pre defined and would depend on the email service provider.

TP-Message-Refernce

The TP-Message-Reference field gives an integer representation of a reference number of the SMS-SUBMIT or SMS-COMMAND submitted to the SC by the MS. The MS increments TP-Message-Reference by 1 for each SMS-SUBMIT or SMS-COMMAND being submitted. The value to be used for each SMS-SUBMIT is obtained by reading the Last-Used-TP-MR value from the SMS Status data field in the SIM card and incrementing this value by 1. After each SMS-SUBMIT has been submitted to the network, the Last-Used-TP-MR value in the SIM is updated with the TP-MR that was used in the SMS-SUBMIT operation. The reference number may possess values in the range 0 to 255. The value in the TP-MR assigned by the MS is the same value which is received at the SC.

In the case where no response or an RP-ERROR with an appropriate cause value is received in response to an SMS-SUBMIT, then the MS shall automatically repeat the SMS-SUBMIT but must use the same -MR value and set the TP-RD bit to 1. The number of times the MS automatically repeats the SMS-SUBMIT shall be in the range 1 to 3 but the precise number is an implementation matter. The automatic repeat mechanism should be capable of being disabled through MMI.

If all automatic attempts fail, the user shall be informed. The failed message shall be stored in the mobile in such a way that the user can request a retransmission using the same

TP-MR value, without the need to re-enter any information. Such storage need only be provided for a single failed message, i.e. the one most recently attempted.

The SC should discard an SMS-SUBMIT which has the TP-RD bit set to a 1 and which has the same TP-MR value as the previous SMS-SUBMIT received from the same originating address. In the case of a discarded SMS-SUBMIT, the SC should respond with an RP-ERROR, in which case the RP-ERROR shall include a SMS-SUBMIT-REPORT with TP-FCS indicating “SM Rejected – Duplicate SM”. In some cases, for backward compatibility with earlier phases and versions of this specification, the SC may be configured to respond with an RP-ACK.

The SMS-STATUS-REPORT also contains a TP-Message-Reference field. The value sent to the MS shall be the same as the TP-Message-Reference value generated by the MS in the earlier SMS-SUBMIT or SMS-COMMAND to which the status report relates.

Oracle Real Application Clusters (RAC)

Real application clustering is a method where multiple instances of oracle accessing a single data store simultaneously, with cache synchronization according to oracle global cache management technology (cache fusion).

Why actually oracle RAC is needed is worth considering. Without RAC in an environment where applications busy accessing the physical database, there is a higher chance of failure. And the reliability factor as well as the scalability factor are also considerably low. Because of these needs, RAC emerged where it could bring about a solution to the above mentioned.


Architecture is arranged in such a way that multiple nodes access the physical data sore concurrently, which can be exceeded up to eight nodes. This provides a complete clustering solution where data between applications are synced, monitored and manged. And it also restart the oracle instances.

In the oracle cluster any node is allowed to update data on the single physical database, SAN (Storage Area Network). The real advantage of this is all the nodes access the same set of data which is updated and changed live. In almost all the value critical applications such as bank systems, this is really important feature since live data is needed for processing.

Since maintaining a single database, it makes the management and administration of the database easy. Even though it shares the data store, in each database servers, it has it's own, application, logs, operating system, and database instance. What is shared here is the all the data and meta data which affects the real data.

RAC is capable of handling fail overs and load balancing as well. In an situation of failure, it can balance the load among the other servers and users won't feel any difference in the service offered to them.

Cache fusion is also another important feature associated with RAC in which instance's cache is copied to a global cache as any node can access the information fast. This allows any server to get the most updated data without actually going to the physical disk. This is like information having in cache memory of a computer.

Benefits of this RAC technology includes, reliability, recoverability, error detection and continuous operation which comes under the main category of high availability and also it supports scalability.

Oracle Database Architecture

For allmost all the application, written today, needs a database to keep the information centralized. For this purpose, a database management system may be used which will help to manage data effectively and efficiently with fast response time.

Oracle is one such famous database management system which supports many activities and supports the required efficiency and accuracy from the architecture itself.

Oracle Relational Database Management System (RDBMS) is consists of two major layers which supports for high response rate: physical layer and logical layer.

What actually happens in the physical layer is, it stores the data as it is, without any relationship among data. In simple terms if anyone peeps in to the physical layer he/she might see some data blocks bt without any idea of relationship among them.

Physical layer consists of three different file types, data files, redo log files and control files. Data files contain the information about the database, basically the raw data which resides in the database. There can be one or more datafiles present in the database and having many of them will lead to enhanced performance of the RDBMS. The maximum amount of datafiles which can be created is limited by the oracle from the variable, "MAXDATAFILES".

Second type of files in the physical layer is the "redo log" files. These files contain the data which can be used to recover the database in a situation of a database failure. It is more like a log which has all the changes of the system. And the important fact to remember is, if the redo log files are lost there is no way of recovering the database. Important to make sure the safety of these files.

Control files are the third type of files in the physical layer which has the information needed to start an instance of the oracle database. For an example it has the information of location of the redo log file etc. Since this is important aspect of the database architecture, multiple copies ot the file is saved in different places.

In logical layer of the orcle architecture, it consists of two layers inside, tablespaces and database schema. The main purpose of the tablespace is to logically group the data. In applications wt we do is to access tables in the database. That table relationship is created by this logical layer which will logically integrate the data and show the applications the relationship in data. Using this logical layer make the administration easy. And also it provide the facility for the data blocks, data files to be spread over a wide diskspace rather than having them in the same disk. Having datafiles in seperate disks have a really good advantage on performance factor as it will cause less traffic in I/O.
Some of the important concepts in this tablespace are "data block", "extent" and "segment". Data block is the actual physical size of one data block in oracle database. The contiguous data blocks are called as extent whereas a set of extents is called as segment.

Database schema is the next layer inside logical layer where the oracle instances dominate. Oracle instances are made via the System Global Area (SGA) and it is a combination of background processes and memory buffers.
SGN referes to share information where data plus control information resides in that. Program Global Area (PGA) is another word that comes along with SGA. Other than the fact that SGA is shared information and PGA is about non shared information most of things in these two are similar.