XMS Guide @ clonzc

Netcat – a couple of useful examples

2010-09-27T21:11:00.001-07:00

One of the Linux command line tools I had initially under-estimated is netcat or just nc. By default, netcat creates a TCP socket either in listening mode (server socket) or a socket that is used in order to connect to a server (client mode). Actually, netcat does not care whether the socket is meant to be a server or a client. All it does is to take the data from stdin and transfer it to the other end across the network.

The simplest example of its usage is to create a server-client chat system. Although this is a very primitive way to chat, it shows how netcat works. In the following examples it is assumed that the machine that creates the listening socket (server) has the 192.168.0.1 IP address. So, create the chat server on this machine and set it to listen to 3333 TCP port:

$ nc -l 3333

On the other end, connect to the server with the following:

$ nc 192.168.0.1 3333

In this case, the keyboard acts as the stdin. Anything you type in the server machine’s terminal is transfered to the client machine and vice-versa.
Transfering Files

In the very same way it can be used to transfer files between two computers. You can create a server that serves the file with the following:

$ cat backup.iso | nc -l 3333

Receive backup.iso on the client machine with the following:

$ nc 192.168.0.1 3333 > backup.iso

As you may have noticed, netcat does not show any info about the progress of the data transfer. This is inconvenient when dealing with large files. In such cases, a pipe-monitoring utility like pv can be used to show a progress indicator. For example, the following shows the total amount of data that has been transfered in real-time on the server side:

$ cat backup.iso | pv -b | nc -l 3333

Of course, the same can be implemented on the client side by piping netcat’s output through pv:

$ nc 192.168.0.1 3333 | pv -b > backup.iso

Other Examples

Netcat is extremely useful for creating a partition image and sending it to a remote machine on-the-fly:

$ dd if=/dev/hdb5 | gzip -9 | nc -l 3333

On the remote machine, connect to the server and receive the partition image with the following command:

$ nc 192.168.0.1 3333 | pv -b > myhdb5partition.img.gz

This might not be as classy as the partition backups using partimage, but it is efficient.

Another useful thing is to compress the critical files on the server machine with tar and have them pulled by a remote machine:

$ tar -czf - /etc/ | nc -l 3333

As you can see, there is a dash in the tar options instead of a filename. This is because tar’s output needs to be passed to netcat.

On the remote machine, the backup is pulled in the same way as before:

$ nc 192.168.0.1 3333 | pv -b > mybackup.tar.gz

Security

It is obvious that using netcat in the way described above, the data travels in the clear across the network. This is acceptable in case of a local network, but, in case of transfers across the internet, then it would be a wise choice to do it through an SSH tunnel.

Using an SSH tunnel has two advantages:

1. The data is transfered inside an encrypted tunnel, so it is well-protected.
2. You do not need to keep any open ports in the firewall configuration of the machine that will act as the server, as the connections will take place through SSH.

You pipe the file to a listening socket on the server machine in the same way as before. It is assumed that an SSH server runs on this machine too.

$ cat backup.iso | nc -l 3333

On the client machine connect to the listening socket through an SSH tunnel:

$ ssh -f -L 23333:127.0.0.1:3333 me@192.168.0.1 sleep 10; \
nc 127.0.0.1 23333 | pv -b > backup.iso

This way of creating and using the SSH tunnel has the advantage that the tunnel is automagically closed after file transfer finishes. For more information and explanation about it please read my article about auto-closing SSH tunnels.
Telnet-like Usage

Netcat can be used in order to talk to servers like telnet does. For example, in order to get the definition of the word “server” from the “WordNet” database at the dict.org dictionary server, I’d do:

$ nc dict.org 2628
220 ..............some WELCOME.....
DEFINE wn server
150 1 definitions retrieved
151 "server" wn "WordNet (r) 2.0"
server
n 1: a person whose occupation is to serve at table (as in a
restaurant) [syn: {waiter}]
2: (court games) the player who serves to start a point
3: (computer science) a computer that provides client stations
with access to files and printers as shared resources to a
computer network [syn: {host}]
4: utensil used in serving food or drink
.
250 ok [d/m/c = 1/0/18; 0.000r 0.000u 0.000s]
QUIT
221 bye [d/m/c = 0/0/0; 16.000r 0.000u 0.000s]

Works as a Port Scanner too

A useful command line flag is -z. When it is used, netcat does not initiate a connection to the server, but just informs about the open port it has found. Also, instead of a single port, it can accept a port-range to scan. For example:

$ nc -z 192.168.0.1 80-90
Connection to 192.168.0.1 80 port [tcp/http] succeeded!

In this example, netcat scanned the 80-90 range of ports and reported that port 80 is open on the remote machine.

The man page contains some more interesting examples, so take the time to read it.
Notes

All the above examples have been performed on Fedora 5/6. Netcat syntax may vary slightly among Linux distributions, so read the man page carefully.

Netcat provides a primitive way to transfer data between two networked computers. I wouldn’t say it’s an absolutely necessary tool in the everyday use, but there are times that this primitive functionality is very useful.

Vi Cheat Sheet

2010-09-02T19:07:00.000-07:00

Modes
Vi has two modes insertion mode and command mode. The editor begins in command mode, where the cursor movement and text deletion and pasting occur. Insertion mode begins upon entering an insertion or change command. [ESC] returns the editor to command mode (where you can quit, for example by typing :q!). Most commands execute as soon as you type them except for "colon" commands which execute when you press the ruturn key.

Quitting
:x Exit, saving changes
:q Exit as long as there have been no changes
ZZ Exit and save changes if any have been made
:q! Exit and ignore any changes

Inserting Text
i Insert before cursor
I Insert before line
a Append after cursor
A Append after line
o Open a new line after current line
O Open a new line before current line
r Replace one character
R Replace many characters

Motion
h Move left
j Move down
k Move up
l Move right
w Move to next word
W Move to next blank delimited word
b Move to the beginning of the word
B Move to the beginning of blank delimted word
e Move to the end of the word
E Move to the end of Blank delimited word
( Move a sentence back
) Move a sentence forward
{ Move a paragraph back
} Move a paragraph forward
0 Move to the begining of the line
$ Move to the end of the line
1G Move to the first line of the file
G Move to the last line of the file
nG Move to nth line of the file
:n Move to nth line of the file
fc Move forward to c
Fc Move back to c
H Move to top of screen
M Move to middle of screen
L Move to botton of screen
% Move to associated ( ), { }, [ ]

Deleting Text
Almost all deletion commands are performed by typing d followed by a motion. For example, dw deletes a word. A few other deletes are:
x Delete character to the right of cursor
X Delete character to the left of cursor
D Delete to the end of the line
dd Delete current line
:d Delete current line

Yanking Text
Like deletion, almost all yank commands are performed by typing y followed by a motion. For example, y$ yanks to the end of the line. Two other yank commands are:
yy Yank the current line
:y Yank the current line

Changing text
The change command is a deletion command that leaves the editor in insert mode. It is performed by typing c followed by a motion. For wxample cw changes a word. A few other change commands are:
C Change to the end of the line
cc Change the whole line

Putting text
p Put after the position or after the line
P Put before the poition or before the line

Buffers
Named buffers may be specified before any deletion, change, yank or put command. The general prefix has the form "c where c is any lowercase character. for example, "adw deletes a word into buffer a. It may thereafter be put back into text with an appropriate "ap.

Markers
Named markers may be set on any line in a file. Any lower case letter may be a marker name. Markers may also be used as limits for ranges.
mc Set marker c on this line
`c Go to beginning of marker c line.
'c Go to first non-blank character of marker c line.

Search for strings
/string Search forward for string
?string Search back for string
n Search for next instance of string
N Search for previous instance of string

Replace
The search and replace function is accomplished with the :s command. It is commonly used in combination with ranges or the :g command (below).
:s/pattern/string/flags Replace pattern with string according to flags.
g Flag - Replace all occurences of pattern
c Flag - Confirm replaces.
& Repeat last :s command

Regular Expressions
. (dot) Any single character except newline
* zero or more occurances of any character
[...] Any single character specified in the set
[^...] Any single character not specified in the set
^ Anchor - beginning of the line
$ Anchor - end of line
\< Anchor - begining of word
\> Anchor - end of word
$...$ Grouping - usually used to group conditions
\n Contents of nth grouping

[...] - Set Examples [A-Z] The SET from Capital A to Capital Z
[a-z] The SET from lowercase a to lowercase z
[0-9] The SET from 0 to 9 (All numerals)
[./=+] The SET containing . (dot), / (slash), =, and +
[-A-F] The SET from Capital A to Capital F and the dash (dashes must be specified first)
[0-9 A-Z] The SET containing all capital letters and digits and a space
[A-Z][a-zA-Z] In the first position, the SET from Capital A to Capital Z
In the second character position, the SET containing all letters

Regular Expression Examples /Hello/ Matches if the line contains the value Hello
/^TEST$/ Matches if the line contains TEST by itself
/^[a-zA-Z]/ Matches if the line starts with any letter
/^[a-z].*/ Matches if the first character of the line is a-z and there is at least one more of any character following it
/2134$/ Matches if line ends with 2134
/$21|35$/ Matches is the line contains 21 or 35
Note the use of ( ) with the pipe symbol to specify the 'or' condition
/[0-9]*/ Matches if there are zero or more numbers in the line
/^[^#]/ Matches if the first character is not a # in the line
Notes:
1. Regular expressions are case sensitive
2. Regular expressions are to be used where pattern is specified

Counts
Nearly every command may be preceded by a number that specifies how many times it is to be performed. For example, 5dw will delete 5 words and 3fe will move the cursor forward to the 3rd occurence of the letter e. Even insertions may be repeated conveniently with thismethod, say to insert the same line 100 times.

Ranges
Ranges may precede most "colon" commands and cause them to be executed on a line or lines. For example :3,7d would delete lines 3-7. Ranges are commonly combined with the :s command to perform a replacement on several lines, as with :.,$s/pattern/string/g to make a replacement from the current line to the end of the file.
:n,m Range - Lines n-m
:. Range - Current line
:$ Range - Last line
:'c Range - Marker c
:% Range - All lines in file
:g/pattern/ Range - All lines that contain pattern

Files
:w file Write to file
:r file Read file in after line
:n Go to next file
:p Go to previos file
:e file Edit file
!!program Replace line with output from program

Other
~ Toggle upp and lower case
J Join lines
. Repeat last text-changing command
u Undo last change
U Undo all changes to line

SMS Web Menu Interface

2009-12-28T21:56:00.000-08:00

SMS Web Menu Interface

When the menu driven web interface is enabled, it is easy to test the ability of sending various types of SMS messages.

To enable the menu driven web interface of the gateway, you must check "Enable menu driven web interface" on the "Web" page of the configuration dialog. When that option is enabled, you can connect to the web interface with a web browser. On the "Web" page of the configuration dialog, there is a setting named "Port number for web interface". To connect to the web interface of the gateway, connect to http://ip.address:port, where "ip.address" is the IP address or host name of the PC running the gateway, and "port" is the port number specified for the web interface.

In a default configuration, the web menu interface can be accessed on the gateway PC by pointing a web browser to http://127.0.0.1:8800.

For more information on configuring the Web Menu Interface, see the help file.

With a web browser, connect to the web port configured for the SMS gateway, and an interface similar to the following will be displayed.

This web page provides a menu driven interface for sending various types of SMS and MMS messages.

For information on how to send specific types of messages, please refer to the appropriate section below:

Send Text Message

To send a text message, simply enter a phone number and the text of your message. If the message is longer than 160 characters, the gateway will automatically use concatenated SMS ("long SMS") message support to send the entire message.

Send Binary Message

Sending a binary message through the web interface typically requires more knowledge of the binary SMS protocol that you are attempting to use. HTML forms are included for simplifying the process of sending Nokia Smart Messaging types, along with a general form for sending any binary message.

Send Nokia Ring Tone

To send a Nokia ring tone, you must have a hex string value for the ring tone data. The hex string format represents two characters for each binary byte of ring tone data. Documentation of the ring tone data format is beyond the scope of this document.

For those who wish to send ring tones programmatically via the Now SMS/MMS Gateway, note that this form includes the following hidden fields which are included as URL parameters when submitting the message to the server:

UDH = 06050415811581

PID = 0

DCS = F7

Send Nokia CLI (Group) Icon

To send a Nokia Group Icon, you must have a hex string value for an OTA Bitmap, as defined by the Nokia Smart Messaging specification. The hex string format represents two characters for each binary byte of OTA Bitmap data. Documentation of the OTA Bitmap data format is beyond the scope of this document.

For those who wish to send Nokia Group icons programmatically via the Now SMS/MMS Gateway, note that this form includes the following hidden fields which are included as URL parameters when submitting the message to the server:

UDH = 06050415831583

PID = 0

DCS = F7

JavaScript in the HTML form adds the hex string "30" to the beginning of the OTA Bitmap string and submits it as the "Data" parameter in the URL.

Send Nokia Operator Logo

Nokia Operator logos are one of the more complicated of the Nokia Smart Messaging formats. To send a Nokia Operator logo, you must have a hex string value for an OTA Bitmap, as defined by the Nokia Smart Messaging specification. The hex string format represents two characters for each binary byte of OTA Bitmap data. Documentation of the OTA Bitmap data format is beyond the scope of this document. You must also know the Mobile Country Code (MCC) and Mobile Network Code (MNC) values of the network operator to which the recipient is subscribed. A link on the form provides more information on MCC and MNC codes, and a pointer to the URL http://www.gsmworld.com/roaming/gsminfo/index.shtml, from which you can look up the MCC and MNC codes of various network operators.

For those who wish to send Nokia Operator logos programmatically via the Now SMS/MMS Gateway, note that this form includes the following hidden fields which are included as URL parameters when submitting the message to the server:

UDH = 06050415821582

PID = 0

DCS = F7

JavaScript in the HTML converts the MCC and MNC codes into the format required by the Nokia Smart Messaging specification, and combines them with the OTA Bitmap data to create a valid operator logo message in the URL "Data" parameter submitted by the form.

Send Nokia Picture Message

Nokia Picture Messaging should not be confused with MMS picture messaging. The Nokia picture messaging format typically only allows for the submission of small specially formatted black and white pictures, whereas MMS provides support for larger color images in a variety of different formats.

To send a Nokia Picture Message, you must have a hex string value for an OTA Bitmap, as defined by the Nokia Smart Messaging specification. The hex string format represents two characters for each binary byte of OTA Bitmap data. Documentation of the OTA Bitmap data format is beyond the scope of this document. A picture message also includes a short text message.

For those who wish to send Nokia Picture Messages programmatically via the Now SMS/MMS Gateway, note that this form includes the following hidden fields which are included as URL parameters when submitting the message to the server:

UDH = 060504158A158A

PID = 0

DCS = F7

JavaScript in the HTML form combines the message text and the OTA bitmap data to create a valid picture message in the URL "Data" parameter submitted by the form.

Send Binary Message Other

The "Send Binary Message Other" form allows for the submission of other types of binary messages. This typically requires more knowledge of the binary SMS protocol that you are attempting to use, but this web form can be convenient for testing.

Send WAP Push Message

It has never been simpler to send a WAP Push message. Simply enter a phone number, a WAP URL (if the "http://" prefix is not included it will be added automatically), and some text to be included in the informational message displayed to the user. The gateway will automatically generate and send a WAP Push "Service Indication" (SI) message to the specified phone number.

Send MMS Message

It no longer requires a degree in rocket science to send an MMS message.

The menu interface provides two methods for sending an MMS message. The "Send MMS Message" option allows you to define a subject, message text, and optionally include multiple content files (uploaded via the browser). Content files may include text files, audio files, image files, SMIL files, and/or other supported MMS content types. The gateway automatically compiles the MMS message file and uses the gateway's built-in MMSC to send the message.

Note that this menu interface also allows for the sending of a pre-compiled MMS message file. If you are sending a pre-compiled MMS message file, that file should be submitted as the only content file for the message, and it should have a ".mms" file extension.

The alternative MMS interface, "Send MMS Notification" is intended for more advanced developers. After creating a binary MMS message file (don't worry the gateway includes tools to help you do this!), and storing the message file on a web server with a MIME type of "application/vnd.wap.mms-message", this dialog shows how the gateway can be used to send a notification to the message recipient that instructs the recipient's phone to connect to the specified URL to retrieve the MMS message content.

Note: When the "Send MMS Notification" function is used, the MMS Notification is sent to the recipient independent of the MMSC built-in to the gateway. The message recipient will fetch the message directly from the URL specified. As the message is not routed through the MMSC, the MMSC cannot provide dynamic content adaptation and conversion services.

Send WAP OTA Settings

The gateway supports sending WAP OTA (Over-the-Air) configuration information to WAP compatible mobile phones. The "Send WAP OTA Settings" option allows a complete WAP configuration profile to be sent to a compatible mobile phone (the gateway supports the Nokia/Ericsson OTA Settings specification).

The web menu interface provides support for GPRS and GSM/CSD (GSM dial-up) configurations.

Settings are operator specific, so please refer to your operator for information on settings that are appropriate for your environment.

Send WAP OTA Bookmark

The gateway supports sending WAP OTA (Over-the-Air) configuration information to WAP compatible mobile phones. The "Send WAP OTA Bookmark" option allows bookmarks to be sent to compatible mobile phones. Simply specify the WAP URL, a title for the bookmark, and a phone number to which the bookmark should be sent. Be forewarned that many phones do not yet support this bookmark feature.

Send Voice Mail Notification

Voice Mail Notification Messages are special SMS messages that are used to tell the user that they have voice mail waiting. On most mobile phones, the phone displays a message prompt, and the user can press a single key to be transferred to voice mail. This voice mail phone number is configurable via the mobile phone settings.

This dialog supports sending special SMS messages to turn on and off the voice mail waiting status.

SCTP Headers

2009-09-30T23:16:00.000-07:00

SCTP Headers

This will be a very brief introduction to the SCTP headers. SCTP has a lot of different types of packets, and hence I will try to follow the RFC's as close as possible and how they depict the different headers, starting with a general overview of the headers applicable to all SCTP packets.

SCTP Generic header format

This is a generic overview of how a SCTP packet is laid out. Basically, you have a common header first with information describing the whole packet, and the source and destination ports etc. See more below for information on the common header.

After the common header a variable number of chunks are sent, up to the maximum possible in the MTU. All chunks can be bundled except for INIT, INIT ACK and SHUTDOWN COMPLETE, which must not be bundled. DATA chunks may be broken down to fit inside the MTU of the packets.

SCTP Common and generic headers

Every SCTP packet contains the Common header as seen above. The header contains four different fields and is set for every SCTP packet.

Source port - bit 0-15. This field gives the source port of the packet, which port it was sent from. The same as for TCP and UDP source port.

Destination port - bit 16-31. This is the destination port of the packet, ie., the port that the packet is going to. It is the same as for the TCP and UDP destination port.

Verification Tag - bit 32-63. The verification tag is used to verify that the packet comes from the correct sender. It is always set to the same value as the value received by the other peer in the Initiate Tag during the association initialization, with a few exceptions:

An SCTP packet containing an INIT chunk must have the Verification tag set to 0.
A SHUTDOWN COMPLETE chunk with the T-bit set must have the verification tag copied from the verification tag of the SHUTDOWN-ACK chunk.
Packets containing ABORT chunk may have the verification tag set to the same verification tag as the packet causing the ABORT.

Checksum - bit 64-95. A checksum calculated for the whole SCTP packet based on the Adler-32 algorithm. Read RFC 2960 - Stream Control Transmission Protocol, appendix B for more information about this algorithm.

All SCTP chunks has a special layout that they all adhere to as can be seen above. This isn't an actual header, but rather a formalized way of how they do look.

Type - bit 0-7. This field specifies the chunk type of the packet, for example is it an INIT or SHUTDOWN chunk or what? Each chunk type has a specific number, and is specified in the image below. Here is a complete list of Chunk types:

Table 2-1. SCTP Types

Chunk Number	Chunk Name
0	Payload Data (DATA)
1	Initiation (INIT)
2	Initiation Acknowledgement (INIT ACK)
3	Selective Acknowledgement (SACK)
4	Heartbeat Request (HEARTBEAT)
5	Heartbeat Acknowledgement (HEARTBEAT ACK)
6	Abort (ABORT)
7	Shutdown (SHUTDOWN)
8	Shutdown Acknowledgement (SHUTDOWN ACK)
9	Operation Error (ERROR)
10	State Cookie (COOKIE ECHO)
11	Cookie Acknowledgement (COOKIE ACK)
12	Reserved for Explicit Congestion Notification Echo (ECNE)
13	Reserved for Congestion Window Reduced (CWR)
14	Shutdown Complete (SHUTDOWN COMPLETE)
15-62	Reserved for IETF
63	IETF-defined chunk extensions
64-126	reserved to IETF
127	IETF-defined chunk extensions
128-190	reserved to IETF
191	IETF-defined chunk extensions
192-254	reserved to IETF
255	IETF-defined chunk extensions

Chunk Flags - bit 8-15. The chunk flags are generally not used but are set up for future usage if nothing else. They are chunk specific flags or bits of information that might be needed for the other peer. According to specifications, flags are only used in DATA, ABORT and SHUTDOWN COMPLETE packets at this moment. This may change however.

A lot of times when you read an RFC, you might run into some old proven problems. The RFC 2960 - Stream Control Transmission Protocol document is one example of this, where they specifically specify that the Chunk flags should always be set to 0 and ignored unless used for something. This is written all over the place, and it begs for problems in the future. If you do firewalling or routing, watch out very carefully for this, since specifications for fields like this may change in the future and hence break at your firewall without any legit reason. This happened before with the implementation of ECN in the IP headers for example. See more in the IP headers section of this chapter.

Chunk Length - bit 16-31. This is the chunk length calculated in bytes. It includes all headers, including the chunk type, chunk flags, chunk length and chunk value. If there is no chunk value, the chunk length will be set to 4 (bytes).

Chunk Value - bit 32-n. This is specific to each chunk and may contain more flags and data pertaining to the chunk type. Sometimes it might be empty, in which case the chunk length will be set to 4.

SCTP ABORT chunk

The ABORT chunk is used to abort an association as previously described in the Shutdown and abort section of this chapter. ABORT is issued upon unrecoverable errors in the association such as bad headers or data.

Type - bit 0-7. Always set to 6 for this chunk type.

Reserved - bit 8-14. Reserved for future chunk flags but not used as of writing this. See the SCTP Common and generic headers for more information about the chunk flags field.

T-bit - bit 15. If this bit is set to 0, the sender had a TCB associated with this packet that it has destroyed. If the sender had no TCB the T-bit should be set to 1.

Length - bit 16-31. Sets the length of the chunk in bytes including error causes.

SCTP COOKIE ACK chunk

The COOKIE ACK chunk is used during the initialization of the connection and never anywhere else in the connection. It must precede all DATA and SACK chunks but may be sent in the same packet as the first of these packets.

Type - bit 0-7. Always set to 11 for this type.

Chunk flags - bit 8-15. Not used so far. Should always be set to 0 according to RFC 2960 - Stream Control Transmission Protocol. You should always watch out for this kind of specific behaviour stated by RFC's since it might change in the future, and hence break your firewalls etc. Just the same as happened with IP and ECN. See the SCTP Common and generic headers section for more information.

Length - bit 16-31. Should always be 4 (bytes) for this chunk.

SCTP COOKIE ECHO chunk

The COOKIE ECHO chunk is used during the initialization of the SCTP connection by the initiating party to reply to the cookie sent by the responding party in the State cookie field in the INIT ACK packet. It may be sent together with DATA chunks in the same packet, but must precede the DATA chunks in such case.

Type - bit 0-7. The chunk type is always set to 10 for this chunk.

Chunk flags - bit 8-15. This field is not used today. The RFC specifies that the flags should always be set to 0, but this might cause trouble as can be seen in the SCTP Common and generic headers section above, specifically the Chunk flags explanation.

Length - bit 16-31. Specifies the length of the chunk, including type, chunk flags, length and cookie fields in bytes.

Cookie - bit 32-n. This field contains the cookie as sent in the previous INIT ACK chunk. It must be the exact same as the cookie sent by the responding party for the other end to actually open the connection. The RFC 2960 - Stream Control Transmission Protocol specifies that the cookie should be as small as possible to insure interoperability, which is very vague and doesn't say much.

SCTP DATA chunk

DATA chunks are used to send actual data through the stream and have rather complex headers in some ways, but not really worse than TCP headers in general. Each DATA chunk may be part of a different stream, since each SCTP connection can handle several different streams.

Type - bit 0-7. The Type field should always be set to 0 for DATA chunks.

Reserved - bit 8-12. Not used today. Might be applicable for change. See SCTP Common and generic headers for more information.

U-bit - bit 13. The U-bit is used to indicate if this is an unordered DATA chunk. If it is, the Stream Sequence Number must be ignored by the receiving host and send it on to the upper layer without delay or tries to re-order the DATA chunks.

B-bit - bit 14. The B-bit is used to indicate the beginning of a fragmented DATA chunk. If this bit is set and the E (ending) bit is not set, it indicates that this is the first fragment of a chunk that has been fragmented into several DATA chunks.

E-bit - bit 15. The E-bit is used to indicate the ending of a fragmented DATA chunk. If this flag is set on a chunk, it signals to the SCTP receiver that it can start reassembling the fragments and pass them on to the upper layer. If a packet has both the BE-bits set to set to 0, it signals that the chunk is a middle part of a fragmented chunk. If both BE-bits are set to 1 it signals that the packet is unfragmented and requires no reassembly et cetera.

Length - bit 16-31. The length of the whole DATA chunk calculated in bytes,including the chunk type field and on until the end of the chunk.

TSN - bit 32-63. The Transmission Sequence Number (TSN) is sent in the DATA chunk, and the receiving host uses the TSN to acknowledge that the chunk got through properly by replying with a SACK chunk. This is an overall value for the whole SCTP association.

Stream Identifier - bit 64-79. The Stream Identifier is sent along with the DATA chunk to identify which stream the DATA chunk is associated with. This is used since SCTP can transport several streams within a single association.

Stream Sequence Number - bit 80-95. This is the sequence number of the chunk for the specific stream identified by the Stream Identifier. This sequence number is specific for each stream identifier. If a chunk has been fragmented, the Stream Sequence Number must be the same for all fragments of the original chunk.

Payload Protocol Identifier - bit 96-127. This value is filled in by the upper layers, or applications using the SCTP protocol as a way to identify to each other the content of the DATA chunk. The field must always be sent, including in fragments since routers and firewalls, et cetera, on the way might need the information. If the value was set to 0, the value was not set by the upper layers.

User data - bit 128-n. This is the actual data that the chunk is transporting. It can be of variable length, ending on an even octet. It is the data in the stream as specified by the stream sequence number n in the stream S.

SCTP ERROR chunk

The ERROR chunk is sent to inform the other peer of any problems within the current stream. Each ERROR chunk can contain one or more Error Causes, which are more specifically detailed in the RFC 2960 - Stream Control Transmission Protocol document. I will not go into further details here than the basic ERROR chunk, since it would be too much information. The ERROR chunk is not fatal in and of itself, but rather details an error that has happened. It may however be used together with an ABORT chunk to inform the peer of the error before killing the connection.

Type - bit 0-7. This value is always set to 9 for ERROR chunks.

Chunk flags - bit 8-15. Not used today. Might be applicable for change. See SCTP Common and generic headers for more information.

Length - bit 16-31. Specifies the length of the chunk in bytes, including all the Error Causes.

Error causes - bit 32-n. Each ERROR chunk may contain one or more Error Causes, which notifies the opposite peer of a problem with the connection. Each Error Cause follows a specific format, as described in the RFC 2960 - Stream Control Transmission Protocol document. We will not go into them here more than to say that they all contain an Cause Code, cause length and cause specific information field. The following Error Causes are possible:

Table 2-2. Error Causes

Cause Value	Chunk Code
1	Invalid Stream Identifier
2	Missing Mandatory Parameter
3	Stale Cookie Error
4	Out of Resource
5	Unresolvable Address
6	Unrecognized Chunk Type
7	Invalid Mandatory Parameter
8	Unrecognized Parameters
9	No User Data
10	Cookie Received While Shutting Down

SCTP HEARTBEAT chunk

The HEARTBEAT chunk is sent by one of the peers to probe and find out if a specific SCTP endpoint address is up. This is sent to the different addresses that was negotiated during the initialization of the association to find out if they are all up.

Type - bit 0-7. The type is always set to 4 for HEARTBEAT chunks.

Chunk flags - bit 8-15. Not used today. Might be applicable for change. See SCTP Common and generic headers for more information.

Length - bit 16-31. The length of the whole chunk, including the Heartbeat Information TLV.

Heartbeat Information TLV - bit 32-n. This is a variable-length parameter as defined inside the RFC 2960 - Stream Control Transmission Protocol document. This is a mandatory parameter for the HEARTBEAT chunks that contains 3 fields, info type = 1, info length and a sender-specific Heartbeat Information parameter. The last field should be a sender-specific information field of some kind, for example a timestamp when the heartbeat was sent and a destination IP address. This is then returned in the HEARTBEAT ACK chunk.

SCTP HEARTBEAT ACK chunk

The HEARTBEAT ACK is used to acknowledge that a HEARTBEAT was received and that the connection is working properly. The chunk is always sent to the same IP address as the request was sent from.

Type - bit 0-7. Always set to 5 for HEARTBEAT ACK chunks.

Chunk flags - bit 8-15. Not used today. Might be applicable for change. See SCTP Common and generic headers for more information.

Chunk length - bit 16-31. The length of the HEARTBEAT ACK chunk including the Heartbeat Information TLV, calculated in bytes.

Heartbeat Information TLV - bit 32-n. This field must contain the Heartbeat Information parameter that was sent in the original HEARTBEAT chunk.

SCTP INIT chunk

The INIT chunk is used to initiate a new association with a destination host, and is the first chunk to be sent by the connecting host. The INIT chunk contains several mandatory fixed length parameters, and some optional variable length parameters. The fixed length mandatory parameters are already in the above headers, and are the Initiate Tag, Advertised Receiver Window Credit, Number of Outbound Streams, Number of Inbound Streams and the Initial TSN parameters. After this comes a couple of optional parameters, they will be listed with the optional parameters paragraph below.

Type - bit 0-7. The type field is always set to 1 for INIT chunks.

Chunk flags - bit 8-15. Not used today. Might be applicable for change. See SCTP Common and generic headers for more information.

Chunk Length - bit 16-31. The chunk length is the length of the whole packet, including everything in the headers, including the optional parameters.

Initiate Tag - bit 32-63. The Initiate Tag is set within the INIT chunk and must be used by the receiver to acknowledge all packets henceforth, within the Verification Tag of the established association. The Initiate Tag may take any value except 0. If the value is 0 anyways, the receiver must react with an ABORT.

Advertised Receiver Window Credit (a_rwnd)- bit 64-95. This is the minimum receiving buffer that the sender of the INIT chunk will allocate for this association, in bytes. This can then be used by the receiver of the a_rwnd, to know how much data it can send out without being SACK'ed. This window should not be lessened, but it might by sending the new a_rwnd in a SACK chunk.

Number of Outbound Streams - bit 96-111. This specifies the maximum number of outbound streams that the connecting host wishes to create to the receiving host. The value must not be 0, and if it is, the receiving host should ABORT the association immediately. There is no negotiation of the minimum number of outbound or inbound streams, it is simply set to the lowest that either host has set in the header.

Number of Inbound Streams - bit 112-127. Specifies the maximum number of inbound connections that the sending peer will allow the receiving host to create in this association. This must not be set to 0, or the receiving host should ABORT the connection. There is no negotiation of the minimum number of outbound or inbound streams, it is simply set to the lowest that either host has set in the header.

Initial TSN - bit 128-159. This value sets the initial Transmit Sequence Number (TSN) that the sender will use when sending data. The field may be set to the same value as the Initiate Tag.

On top of the above mandatory fixed length headers, there are also some optional variable length parameters that might be set, and at least one of the IPv4, IPv6 or Hostname parameters must be set. Only one Hostname may be set, and if a Hostname is set, no IPv4 or IPv6 parameters may be set. Multiple IPv4 and IPv6 parameters may also be set in the same INIT chunk. Also, none of these parameters needs to be set in case the sender only has one address that can be reached, which is where the chunk should be coming from. These parameters are used to set up which addresses may be used to connect to the other end of the association. This is a full list of all the parameters available in the INIT chunk:

Table 2-3. INIT Variable Parameters

Parameter Name	Status	Type Value
IPv4 Address	Optional	5
IPv6 Address	Optional	6
Cookie Preservative	Optional	9
Host Name Address	Optional	11
Supported Address Types	Optional	12
Reserved for ECN Capable	Optional	32768

Below we describe the three most common Parameters used in the INIT chunk.

The IPv4 parameter is used to send an IPv4 address in the INIT chunk. The IPv4 address can be used to send data through the association. Multiple IPv4 and IPv6 addresses can be specified for a single SCTP association.

Parameter Type - bit 0-15. This is always set to 5 for IPv4 address parameters.

Length - bit 16-31. This is always set to 8 for IPv4 address parameters.

IPv4 Address - bit 32-63. This is an IPv4 address of the sending endpoint.

This parameter is used to send IPv6 addresses in the INIT chunk. This address can then be used to contact the sending endpoint with this association.

Type - bit 0-15. Always set to 6 for the IPv6 parameters.

Length bit 16-31. Always set to 20 for IPv6 parameters.

IPv6 address - bit 32-159. This is an IPv6 address of the sending endpoint that can be used to connect to by the receiving endpoint.

The Hostname parameter is used to send a single hostname as an address. Thea receiving host must then look up the hostname and use any and/or all of the addresses it receives from there. If a hostname parameter is sent, no other IPv4, IPv6 or Hostname parameters may be sent.

Type - bit 0-15. This is always set to 11 for Hostname Parameters.

Length - bit 16-31. The length of the whole parameter, including type, length and hostname field. The Hostname field is variable length. The length is counted in bytes.

Hostname - bit 32-n. A variable length parameter containing a hostname. The hostname is resolved by the receiving end to get the addresses that can be used to contact the sending endpoint.

SCTP INIT ACK chunk

The INIT ACK chunk is sent in response to a INIT chunk and contains basically the same headers, but with values from the recipient of the original INIT chunk. In addition, it has two extra variable length parameters, the State Cookie and the Unrecognized Parameter parameters.

Type - bit 0-7. This header is always set to 2 for INIT ACK chunks.

Chunk flags - bit 8-15. Not used today. Might be applicable for change. See SCTP Common and generic headers for more information.

Chunk Length - bit 16-31. The chunk length is the length of the whole packet, including everything in the headers, and the optional parameters.

Initiate Tag - bit 32-63. The receiver of the Initiate Tag of the INIT ACK chunk must save this value and copy it into the Verification Tag field of every packet that it sends to the sender of the INIT ACK chunk. The Initiate Tag must not be 0, and if it is, the receiver of the INIT ACK chunk must close the connection with an ABORT.

Advertised Receiver Window Credit (a_rwnd) - bit 64-95. The dedicated buffers that the sender of this chunk has located for traffic, counted in bytes. The dedicated buffers should never be lowered to below this value.

Number of Outbound Streams - bit 96-111. How many outbound streams that the sending host wishes to create. Must not be 0, or the receiver of the INIT ACK should ABORT the association. There is no negotiation of the minimum number of outbound or inbound streams, it is simply set to the lowest that either host has set in the header.

Number of Inbound Streams - bit 112-127. How many inbound streams that the sending endpoint is willing to accept. Must not be 0, or the receiver of the INIT ACK should ABORT the association. There is no negotiation of the minimum number of outbound or inbound streams, it is simply set to the lowest that either host has set in the header.

Initial TSN - bit 128-159. This is set to the Initial Transmission Sequence Number (I-TSN) which will be used by the sending party in the association to start with.

After this point, the INIT ACK chunk continues with optional variable-length parameters. The parameters are exactly the same as for the INIT chunk, with the exception of the addition of the State Cookie and the Unrecognized Parameters parameter, and the deletion of the Supported Address Types parameter. The list in other words look like this:

Table 2-4. INIT ACK Variable Parameters

Parameter Name	Status	Type Value
IPv4 Address	Optional	5
IPv6 Address	Optional	6
State Cookie	Mandatory	7
Unrecognized Parameters	Optional	8
Cookie Preservative	Optional	9
Host Name Address	Optional	11
Reserved for ECN Capable	Optional	32768

The State Cookie is used in INIT ACK to send a cookie to the other host, and until the receiving host has replied with a COOKIE ECHO chunk, the association is not guaranteed. This is to prevent basically the same as a SYN attack in TCP protocol.

Type - bit 0-15. Always set to 7 for all State Cookie parameters.

Length - bit 16-31. The size of the whole parameter, including the type, length and State Cookie field in bytes.

State Cookie - bit 31-n. This parameter contains a cookie of variable length. For a description on how this cookie is created, see the RFC 2960 - Stream Control Transmission Protocol document.

SCTP SACK chunk

The SACK chunk is used to tell the sender of DATA chunks which chunks has been received and where there has been a gap in the stream, based on the received TSN's. Basically, the SACK chunk acknowledges that it has received data up to a certain point (the Cumulative TSN Ack parameter), and then adds Gap Ack Blocks for all of the data that it has received after the Cumulative TSN Ack point. A SACK chunk must not be sent more than once for every DATA chunk that is received.

Type - bit 0-7. This header is always set to 3 for SACK chunks.

Chunk flags - bit 8-15. Not used today. Might be applicable for change. See SCTP Common and generic headers for more information.

Chunk Length - bit 16-31. The chunk length is the length of the whole chunk, including everything in the headers and all the parameters.

Cumulative TSN Ack - bit 32-63. This is the Cumulative TSN Ack parameter, which is used to acknowledge data. The DATA chunk receiver will use this field to tell the sending host that it has received all data up to this point of the association. After this point, all data that has not been specifically acknowledged by the Gap Ack Blocks will, basically, be considered unaccounted for.

Advertised Receiver Window Credit (a_rwnd) - bit 64-95. The a_rwnd field is basically the same as the a_rwnd in the INIT and INIT ACK chunks, but can be used to raise or lower the a_rwnd value. Please read more in the RFC 2960 - Stream Control Transmission Protocol document about this.

Number of Gap Ack Blocks - bit 96-111. The number of Gap Ack Blocks listed in this chunk. Each Gap Ack Block takes up 32 bits in the chunk.

Number of Duplicate TSNs - bit 112-127. The number of DATA chunks that has been duplicated. Each duplicated TSN is listed after the Gap Ack Blocks in the chunk, and each TSN takes 32 bits to send.

Gap Ack Block #1 Start - bit 128-143. This is the first Gap Ack Block in the SACK chunk. If there are no gaps in the received DATA chunk TSN numbers, there will be no Gap Ack Blocks at all. However, if DATA chunks are received out of order or some DATA chunks where lost during transit to the host, there will be gaps. The gaps that has been seen will be reported with Gap Ack Blocks. The Gap Ack Block start point is calculated by adding the Gap Ack Block Start parameter to the Cumulative TSN value. The calculated value is the start of the block.

Gap Ack Block #1 End - bit 144-159. This value reports the end of the first Gap Ack Block in the stream. All the DATA chunks with the TSN between the Gap Ack Block Start and the Gap Ack Block End has been received. The Gap Ack Block End value is added to the Cumulative TSN, just as the Start parameter, to get the actual last TSN of the block chunks to be Acknowledged.

Gap Ack Block #N Start - bits variable. For every Gap Ack Block counted in the Number of Gap Ack Blocks parameter, one Gap Ack Block is added, until the final N block. Ie, if Number of Gap Ack Blocks = 2, then there will be two Gap Ack Blocks in the SACK chunk. This is the last one simply, and contains the same type of value as the Gap Ack Block #1 Start.

Gap Ack Block #N End - bits variable. Same as for the Gap Ack Block #N End, but for the end of the gap.

Duplicate TSN #1 - bits variable. These fields report a duplicate TSN, in which case we have already received a specific chunk, but receive the same TSN several times more. This can either be router glitches (retransmitting already sent data) or a case of retransmission from the sending endpoint, or a score of other possibilities. Each instance of a duplicate TSN should be reported once. For example, if 2 duplicate TSN's has been received after acknowledging the first one, each of these duplicate TSN's should be sent sent in the next SACK message that is being sent. If even more duplicate TSN's should appear after this second SACK is sent, the new duplicates should be added in the next SACK, and so on.

Duplicate TSN #X - bits variable. This is the last duplicate TSN parameter, containing the same type of information as the first parameter.

SCTP SHUTDOWN chunk

The SHUTDOWN chunk is issued when one of the endpoints of a connection wants to close the current association. The sending party must empty all of its sending buffers before sending the SHUTDOWN chunk, and must not send any more DATA chunks afterwards. The receiver must also empty its sending buffers and must then send the responding SHUTDOWN ACK chunk.

Type - bit 0-7. This header is always set to 7 for SHUTDOWN chunks.

Chunk flags - bit 8-15. Not used today. Might be applicable for change. See SCTP Common and generic headers for more information.

Chunk Length - bit 16-31. The chunk length is the length of the whole packet, including the Cumulative TSN Ack parameter. The length of the SHUTDOWN chunk should always be 8.

Cumulative TSN Ack - bit 32-63. This is a Cumulative TSN Ack field, just the same as in the SACK chunk. The Cumulative TSN Ack acknowledges the last TSN received in sequence from the opposite endpoint. This parameter does not, nor can the rest of the SHUTDOWN chunk either, acknowledge Gap Ack Blocks. The lack of a Gap Ack Block in the SHUTDOWN chunk that was acknowledged before should not be interpreted as if the previously acknowledged block was lost again.

SCTP SHUTDOWN ACK chunk

The SHUTDOWN ACK chunk is used to acknowledge a SHUTDOWN chunk that has been received. Before the SHUTDOWN ACK chunk is sent, all data in the sending buffers should be sent, but the buffers must not accept any new data from the application. SCTP does not support half-open connections as TCP does.

Type - bit 0-7. This header is always set to 8 for SHUTDOWN ACK chunks.

Chunk flags - bit 8-15. Not used today. Might be applicable for change. See SCTP Common and generic headers for more information.

Chunk Length - bit 16-31. The chunk length is the length of the whole chunk. The length of the SHUTDOWN ACK chunk should always be 4.

SCTP SHUTDOWN COMPLETE chunk

The SHUTDOWN COMPLETE chunk is sent, by the originating host of the SHUTDOWN, in response to the SHUTDOWN ACK chunk. It is sent to acknowledge that the association is finally closed.

Type - bit 0-7. Always set to 14 for SHUTDOWN COMPLETE chunks.

Reserved - bit 8-14. Not used today. Might be applicable for change. See SCTP Common and generic headers for more information.

T-bit - bit 15. The T-bit is not set to signal that the sending host had a Transmission Control Block (TCB) associated with this connection and that it destroyed. If the T-bit was set, it had no TCB to destroy.

Length - bit 16-31. This is always set to 4 for SHUTDOWN COMPLETE chunks, since the chunk should never be any larger, as long as no updates to the standards are made.

SCTP Characteristics

2009-09-30T23:15:00.000-07:00

SCTP Characteristics

Stream Control Transmission Protocol (SCTP) is a relatively new protocol in the game, but since it is growing in usage and complements the TCP and UDP protocols, I have chosen to add this section about it. It has an even higher reliability than TCP, and at the same time a lower overhead from protocol headers.

SCTP has a couple of very interesting features that can be interesting. For those who wish to learn more about this, read the RFC 3286 - An Introduction to the Stream Control Transmission Protocol and RFC 2960 - Stream Control Transmission Protocol document. The first document is an introduction to SCTP and should be very interesting to people who are still in need of more information. The second document is the actual specification for the protocol, which might be less interesting unless you are developing for the protocol or are really interested.

The protocol was originally developed for Telephony over IP, or Voice over IP (VoIP), and has some very interesting attributes due to this. Industry grade VoIP requires very high reliability for one, and this means that a lot of resilience has to be built into the system to handle different kind of problems. The following is a list of the basic features of SCTP.

Unicast with Multicast properties. This means it is a point-to-point protocol but with the ability to use several addresses at the same end host. It can in other words use different paths to reach the end host. TCP in comparison breaks if the transport path breaks, unless the IP protocol corrects it.
Reliable transmission. It uses checksums and SACK to detect corrupted, damaged, discarded, duplicated and reordered data. It can then retransmit data as necessary. This is pretty much the same as TCP, but SCTP is more resilient when it comes to reordered data and allows for faster pickups.
Message oriented. Each message can be framed and hence you can keep tabs on the structure and order of the datastream. TCP is byte oriented and all you get is a stream of bytes without any order between different data inside. You need an extra layer of abstraction in TCP in other words.
Rate adaptive. It is developed to cooperate and co-exist with TCP for bandwidth. It scales up and down based on network load conditions just the same as TCP. It also has the same algorithms for slow starting when packets where lost. ECN is also supported.
Multi-homing. As previously mentioned, it is able to set up different end nodes directly in the protocol, and hence doesn't have to rely on the IP layer for resilience.
Multi-streaming. This allows for multiple simultaneous streams inside the same stream. Hence the name Stream Control Transmission Protocol. A single stream can for example be opened to download a single webpage, and all the images and html documents can then be downloaded within the same stream simultaneously. Or why not a database protocol which can create a separate control stream and then use several streams to receive the output from the different queries simultaneously.
Initiation. 4 packet initiation of connections where packet 3 and 4 can be used to send data. The equivalent of syncookies is implemented by default to avoid DoS attacks. INIT collision resolution to avoid several simultaneous SCTP connections.

This list could be made even longer, but I will not. Most of this information is gathered from the RFC 3286 - An Introduction to the Stream Control Transmission Protocol document, so read on there for more information.

In SCTP we talk about chunks, not packets or windows anymore. An SCTP frame can contain several different chunks since the protocol is message oriented. A chunk can either be a control or a data chunk. Control chunks is used to control the session, and data chunks are used to send actual data.

Initialization and association

Each connection is initialized by creating an association between the two hosts that wants to talk to each other. This association is initialized when a user needs it. It is later used as needed.

The initialization is done through 4 packets. First an INIT chunk is sent, which is replied to with an INIT ACK containing a cookie, after this the connection can start sending data. However, two more packets are sent in the initialization. The cookie is replied to with a COOKIE ECHO chunk, which is finally replied to with a COOKIE ACK chunk.

Data sending and control session

SCTP can at this point send data. In SCTP there are control chunks and data chunks, as previously stated. Data chunks are sent using DATA chunks, and DATA chunks are acknowledged by sending a SACK chunk. This works practically the same as a TCP SACK. SACK chunks are control chunks.

On top of this, there are some other control chunks that can be seen. HEARTBEAT and HEARTBEAT ACK chunks for one, and ERROR chunks for another. HEARTBEATs are used to keep the connection alive, and ERROR is used to inform of different problems or errors in the connection, such as invalid stream id's or missing mandatory parameters et cetera.

Shutdown and abort

The SCTP connection is finally closed by either an ABORT chunk or by a graceful SHUTDOWN chunk. SCTP doesn't have a half-closed state as TCP, in other words one side can not continue sending data while the other end has closed its sending socket.

When the user/application wants to close the SCTP socket gracefully, it tells the protocol to SHUTDOWN. SCTP then sends all the data still in its buffers, and then sends a SHUTDOWN chunk. When the other end receives the SHUTDOWN, it will stop accepting data from the application and finish sending all the data. Once it has gotten all the SACK's for the data, it will send a SHUTDOWN ACK chunk and once the closing side has received this chunk, it will finally reply with a SHUTDOWN COMPLETE chunk. The whole session is now closed.

Another way of closing a session is to ABORT it. This is an ungraceful way of removing an SCTP association. When a connecting party wants to remove an SCTP association instantaneously, it sends an ABORT chunk with all the right values signed. All data in the buffers et cetera will be discarded and the association will then be removed. The receiving end will do the same after verifying the ABORT chunk.

SS7 Details

2009-08-09T10:37:00.000-07:00

Message Transfer Part (MTP)

The Message Transfer Part (MTP) layer of the SS7 protocol provides the routing and network interface capabilities that support SCCP, TCAP, and ISUP. Message Transfer part (MTP) is divided into three levels.

MTP Level 1 (Physical layer) defines the physical, electrical, and functional characteristics of the digital signaling link. Physical interfaces defined include E-1(2048 kb/s; 32 64 kb/s channels), DS-1 (1544 kb/s; 24 64 kp/s channels), V.35 (64 kb/s),DS-0 (64 kb/s), and DS-0A (56 kb/s).

MTP Level 2 provides the reliability aspects of MTP including error monitoring and recovery. (MTP-2) is a signalling link which together with MTP-3 provides reliable transfer of signalling messages between two directly connected signalling points.

MTP Level 3 provides the link, route, and traffic management aspects of MTP. MTP 3, thus ensures reliable transfer of the signalling messages, even in the case of the failure of the signalling links and signalling transfer points. The protocol therefore includes the appropriate functions and procedures necessary both to inform the remote parts of the signalling network of the consequences of a fault, and appropriately reconfigure the routing of messages through the signalling network.

Signaling Connection Control Part (SCCP)

The Signaling Connection Control Part (SCCP) layer of the SS7 stack provides provides connectionless and connection-oriented network services and global title translation (GTT) capabilities above MTP Level 3. SCCP is used as the transport layer for TCAP-based services. It offers both Class 0 (Basic) and Class 1 (Sequenced) connectionless services. SCCP also provides Class 2 (connection oriented) services, which are typically used by Base Station System Application Part, Location Services Extension (BSSAP-LE). In addition, SCCP provides Global Title Translation (GTT) functionality.

The signaling connection control part (SCCP) provides two major functions that are lacking in the MTP. The first of these is the capability to address applications within a signaling point. The MTP can only receive and deliver messages from a node as a whole; it does not deal with software applications within a node.

While MTP network-management messages and basic call-setup messages are addressed to a node as a whole, other messages are used by separate applications (referred to as subsystems) within a node. Examples of subsystems are 800 call processing, calling-card processing, advanced intelligent network (AIN), and custom local-area signaling services (CLASS) services (e.g., repeat dialing and call return). The SCCP allows these subsystems to be addressed explicitly.

The signaling connection control part (SCCP) provides two major functions that are lacking in the MTP. The first of these is thecapability to address applications within a signaling point. The MTP can only receive and deliver messages from a node as a whole; it does not deal with software applications within a node.

The second function provided by the SCCP is Global Title translation, the ability to perform incremental routing using a capability called global title translation (GTT). GTT frees originating signaling points from the burden of having to know every potential destination to which they might have to route a message. A switch can originate a query, for example, and address it to an STP along with a request for GTT. The receiving STP can then examine a portion of the message, make a determination as to where the message should be routed, and then route it.

For example, calling-card queries (used to verify that a call can be properly billed to a calling card) must be routed to an SCP designated by the company that issued the calling card. Rather than maintaining a nationwide database of where such queries should be routed (based on the calling-card number), switches generate queries addressed to their local STPs, which, using GTT, select the correct destination to which the message should be routed. Note that there is no magic here; STPs must maintain a database that enables them to determine where a query should be routed. GTT effectively centralizes the problem and places it in a node (the STP) that has been designed to perform this function.

In performing GTT, an STP does not need to know the exact final destination of a message. It can, instead, perform intermediate GTT, in which it uses its tables to find another STP further along the route to the destination. That STP, in turn, can perform final GTT, routing the message to its actual destination.

Intermediate GTT minimizes the need for STPs to maintain extensive information about nodes that are far removed from them. GTT also is used at the STP to share load among mated SCPs in both normal and failure scenarios. In these instances, when messages arrive at an STP for final GTT and routing to a database, the STP can select from among available redundant SCPs. It can select an SCP on either a priority basis (referred to as primary backup) or so as to equalize the load across all available SCPs (referred to as load sharing).

Transaction Capabilities Application Part (TCAP)

Transaction Capabilities Application Part (TCAP) defines the messages and protocol used to communicate between applications (deployed as subsystems) in nodes. It is used for database services such as calling card, 800, and AIN as well as switch-to-switch services including repeat dialing and call return. Because TCAP messages must be delivered to individual applications within the nodes they address, they use the SCCP for transport.

TCAP enables the deployment of advanced intelligent network services by supporting non-circuit related information exchange between signalling points using the SCCP connectionless service. TCAP messages are contained within the SCCP portion of an MSU. A TCAP message is comprised of a transaction portion and a component portion.

TCAP supports the exchange of non-circuit related data between applications across the SS7 network using the SCCP connectionless service. Queries and responses sent between SSPs and SCPs are carried in TCAP messages. For example, an SSP sends a TCAP query to determine the routing number associated with a dialed 800/888 number and to to check the personal identification number (PIN) of a calling card user. In mobile networks (IS-41 and GSM), TCAP carries Mobile Application Part (MAP) messages sent between mobile switches and databases to support user authentication, equipment identification, and roaming.

ISDN User Part (ISUP)

ISUP (ISDN User Part) defines the messages and protocol used in the establishment and tear down of voice and data calls over the public switched telephone network (PSTN), and to manage the trunk network on which they rely. Despite its name, ISUP is used for both ISDN and non–ISDN calls. In the North American version of SS7, ISUP messages rely exclusively on MTP to transport messages between concerned nodes.

ISUP controls the circuits used to carry either voice or data traffic. In addition, the state of circuits can be verified and managed using ISUP. The management of the circuit infrastructure can occur both at the individual circuit level and for groups of circuits.

Services that can be defined using ISUP include: Switching, Voice mail, Internet offload. ISUP is ideal for applications such as switching and voice mail in which calls are routed between endpoints.

When used in conjunction with TCAP and SIGTRAN, ISUP becomes an enabler for Internet offload solutions in which Internet sessions of relatively long duration can be isolated from relatively brief phone conversations.

A simple call flow using ISUP signaling is as follows:

Call set up: When a call is placed to an out-of-switch number, the originating SSP transmits an ISUP initial address message (IAM) to reserve an idle trunk circuit from the originating switch to the destination switch. The destination switch rings the called party line if the line is available and transmits an ISUP address complete message (ACM) to the originating switch to indicate that the remote end of the trunk circuit has been reserved. The STP routes the ACM to the originating switch which rings the calling party's line and connects it to the trunk to complete the voice circuit from the calling party to the called party.

Call connection: When the called party picks up the phone, the destination switch terminates the ringing tone and transmits an ISUP answer message (ANM) to the originating switch via its home STP. The STP routes the ANM to the originating switch which verifies that the calling party's line is connected to the reserved trunk and, if so, initiates billing.

Call tear down: If the calling party hangs-up first, the originating switch sends an ISUP release message (REL) to release the trunk circuit between the switches. The STP routes the REL to the destination switch. If the called party hangs up first, or if the line is busy, the destination switch sends an REL to the originating switch indicating the release cause (e.g., normal release or busy). Upon receiving the REL, the destination switch disconnects the trunk from the called party's line, sets the trunk state to idle, and transmits an ISUP release complete message (RLC) to the originating switch to acknowledge the release of the remote end of the trunk circuit. When the originating switch receives (or generates) the RLC, it terminates the billing cycle and sets the trunk state to idle in preparation for the next call.

Mobile Application Part (MAP)

Mobile Application Part (MAP) messages sent between mobile switches and databases to support user authentication, equipment identification, and roaming are carried by TCAP. In mobile networks (IS-41 and GSM) when a mobile subscriber roams into a new mobile switching center (MSC) area, the integrated visitor location register requests service profile information from the subscriber's home location register (HLR) using MAP (mobile application part) information carried within TCAP messages.

The Mobile Application Part (MAP), one of protocols in the SS7 suite, allows for the implementation of mobile network (GSM) signaling infrastructure. The premise behind MAP is to connect the distributed switching elements, called mobile switching centers (MSCs) with a master database called the Home Location Register (HLR). The HLR dynamically stores the current location and profile of a mobile network subscriber. The HLR is consulted during the processing of an incoming call. Conversely, the HLR is updated as the subscriber moves about the network and is thus serviced by different switches within the network.

MAP has been evolving as wireless networks grow, from supporting strictly voice, to supporting packet data services as well. The fact that MAP is used to connect NexGen elements such as the Gateway GPRS Support node (GGSN) and Serving Gateway Support Node (SGSN) is a testament to the sound design of the GSM signaling system.

MAP has several basic functions:

* Mechanism for a Gateway-MSC (GMSC) to obtain a routing number for an incoming call

* Mechanism for an MSC via integrated Visitor Location Register (VLR) to update subscriber status and routing number.

* Subscriber CAMEL trigger data to switching elements via the VLR

* Subscriber supplementary service profile and data to switching elements via the VLR.

Intelligent Network Application Part (INAP)

Intelligent Network Application Part (INAP) is the signaling protocol used in Intelligent Networking. Developed by the International Telecommunications Union (ITU), IN is recognized as a global standard. Within the International Telecommunications Union, a total functionality of the IN has been defined and implemented in digestible segments called capability sets. The first version to be released was Capability Set 1 (CS-1). Currently CS-2 is defined and available. The CAMEL Application Part (CAP) is a derivative of INAP and enables the use of INAP in mobile GSM networks.

INAP is a signaling protocol between a service switching point (SSP), network media resources (intelligent peripherals), and a centralized network database called a service control point (SCP). The SCP consists of operator or 3rd party derived service logic programs and data.

Service Switching Point (SSP) is a physical entity in the Intelligent Network that provides the switching functionality. SSP the point of subscription for the service user, and is responsible for detecting special conditions during call processing that cause a query for instructions to be issued to the SCP.
The SSP contains Detection Capability to detect requests for IN services. It also contains capabilities to communicate with other physical entities containing SCF, such as SCP, and to respond to instructions from the other physical entities. Functionally, an SSP contains a Call Control Function, a Service Switching Function, and, if the SSP is a local exchange, a Call Control Agent Function. It also may optionally contain Service Control Function, and/or a Specialized Resource Function, and/or a Service Data Function. The SSP may provide IN services to users connected to subtending Network Access Points.
The SSP is usually provided by the traditional switch manufacturers. These switches are programmable and they can be implemented using multipurpose processors. The main difference of SSP from an ordinary switch is in the software where the service control of IN is separated from the basic call control.
Service Control Point (SCP) validates and authenticates information from the service user, processing requests from the SSP and issuing responses.The SCP stores the service provider instructions and data that direct switch processing and provide call control. At predefined points during processing an incoming or outgoing call, the switch suspends what it is doing, packages up information it has regarding the processing of the call, and queries the SCP for further instruction. The SCP executes user-defined programs that analyze the current state of the call and the information received from the switch. The programs can then modify or create the call data that is sent back to the switch. The switch then analyzes the information received from the SCP and follows the provided instruction to further process the call.
Functionally, an SCP contains Service Control Function (SCF) and optionally also Service Data Function (SDF). The SCF is implemented in Service Logic Programs (SLP). The SCP is connected to SSPs by a signalling network. Multiple SCPs may contain the same SLPs and data to improve service reliability and to facilitate load sharing between SCPs. In case of external Service Data Point (SDP) the SCF can access data through a signalling network. The SDP may be in the same network as the SCP, or in another network. The SCP can be connected to SSPs, and optionally to IPs, through the signalling network. The SCP can also be connected to an IP via an SSP relay function. The SCP comprises the SCP node, the SCP platform, and applications. The node performs functions common to applications, or independent of any application; it provides all functions for handling service-related, administrative, and network messages. These functions include message discrimination, distribution, routing, and network management and testing. For example, when the SCP node receives a service-related message, it distributes the incoming message to the proper application. In turn, the application issues a response message to the node, which routes it to the appropriate network elements. The SCP node gathers data on all incoming and outgoing messages to assist in network administration and cost allocation. This data is collected at the node, and transmitted to an administrative system for processing.
Intelligent Peripheral (IP) provides resources such as customized and concatenated voice announcements, voice recognition, and Dual Tone Multi-Frequencies (DTMF) digit collection, and contains switching matrix to connect users to these resources. The IP supports flexible information interactions between a user and the network. Functionally, the IP contains the Special Resource Function. The IP may directly connect to one or more SSPs, and/or may connect to the signalling network.

Service Management Point (SMP) performs service management control, service provision control, and service deployment control. Examples of functions it can perform are database administration, network surveillance and testing, network traffic management, and network data collection. Functionally, the SMP contains the Service Management Function and, optionally, the Service Management Access Function and the Service Creation Environment
Function. The SMP can access all other Physical Entities.

Conceptual model of the Intelligent Network :

The IN standards present a conceptual model of the Intelligent Network that model and abstract the IN functionality in four planes:

The Service Plane (SP): This plane is of primary interest to service users and providers. It describes services and service features from a user perspective, and is not concerned with how the services are implemented within the network.
The Global Functional Plane (GFP): The GFP is of primary interest to the service designer. It describes units of functionality, known as service independent building blocks (SIBs) and it is not concerned with how the functionality is distributed in the network. Services and service features can be realised in the service plane by combining SIBs in the GFP.
The Distributed Functional Plane (DFP): This plane is of primary interest to network providers and designers. It defines the functional architecture of an IN-structured network in terms of network functionality, known as functional entities (FEs). SIBs in the GFP are realised in the DFP by a sequence of functional entity actions (FEAs) and their resulting information flows.
The Physical Plane (PP): Real view of the physical network.The PP is of primary interest to equipment providers. It describes the physical architecture for an IN-structured network in terms of physical entities (PEs) and the interfaces between them. The functional entities from the DFP are realised by physical entities in the physical plane.

Services that can be defined with INAP include:

Single number service: one number reaches a local number associated with the service
Personal access service: provide end user management of incoming calls
Disaster recovery service: define backup call destinations in case of disaster
Do not disturb service: call forward
Virtual private network short digit extension dialing service

Advantages created by the IN architecture:

extensive use of information processing techniques;
efficient use of network resources;
modularization of network functions;
integrated service creation and implementation by means of reusable standard network functions;
flexible allocation of network functions to physical entities;
portability of network functions among physical entities;
standardised communication between network functions via service independent interfaces;
customer control over their specific service attributes;
standardised management of service logic.

Signalling System #7 (SS7)

2009-08-09T10:24:00.000-07:00

There are two essential components to all telephone calls. The first, and most obvious, is the actual content—our voices, faxes, modem data, etc. The second is the information that instructs telephone exchanges to establish connections and route the “content” to an appropriate destination. Telephony signaling is concerned with the creation of standards for the latter to achieve the former. These standards are known as protocols. SS7 or Signaling System Number 7 is simply another set of protocols that describe a means of communication between telephone switches in public telephone networks. They have been created and controlled by various bodies around the world, which leads to some specific local variations, but the principal organization with responsibility for their administration is the International Telecommunications Union or ITU-T.

Signalling System Number 7 (SS#7 or C7) is the protocol used by the telephone companies for interoffice signalling. In the past, in-band signalling techniques were used on interoffice trunks. This method of signalling used the same physical path for both the call-control signalling and the actual connected call. This method of signalling is inefficient and is rapidly being replaced by out-of-band or common-channel signalling techniques.

To understand SS7 we must first understand something of the basic inefficiency of previous signaling methods utilized in the Public Switched Telephone Network (PSTN). Until relatively recently, all telephone connections were managed by a variety of techniques centered on “in band” signaling.

A network utilizing common-channel signalling is actually two networks in one:

1. First there is the circuit-switched "user" network which actually carries the user voice and data traffic. It provides a physical path between the source and destination.
2. The second is the signalling network which carries the call control traffic. It is a packet-switched network using a common channel switching protocol.

The original common channel interoffice signalling protocols were based on Signalling System Number 6 (SS#6). Today SS#7 is being used in new installations worldwide. SS#7 is the defined interoffice signalling protocol for ISDN. It is also in common use today outside of the ISDN environment.

The primary function of SS#7 is to provide call control, remote network management, and maintenance capabilities for the inter- office telephone network. SS#7 performs these functions by exchanging control messages between SS#7 telephone exchanges (signalling points or SPs) and SS#7 signalling transfer points (STPs).

The switching offices (SPs) handle the SS#7 control network as well as the user circuit-switched network. Basically, the SS#7 control network tells the switching office which paths to establish over the circuit-switched network. The STPs route SS#7 control packets across the signalling network. A switching office may or may not be an STP.

SS7 Protocol layers:

The SS7 network is an interconnected set of network elements that is used to exchange messages in support of telecommunications functions. The SS7 protocol is designed to both facilitate these functions and to maintain the network over which they are provided. Like most modern protocols, the SS7 protocol is layered.

Physical Layer (MTP-1)

This defines the physical and electrical characteristics of the signaling links of the SS7 network. Signaling links utilize DS–0 channels and carry raw signaling data at a rate of 56 kbps or 64 kbps (56 kbps is the more common implementation).

Message Transfer Part—Level 2 (MTP-2)

The level 2 portion of the message transfer part (MTP Level 2) provides link-layer functionality. It ensures that the two end points of a signaling link can reliably exchange signaling messages. It incorporates such capabilities as error checking, flow control, and sequence checking.

Message Transfer Part—Level 3 (MTP-3)

The level 3 portion of the message transfer part (MTP Level 3) extends the functionality provided by MTP level 2 to provide network layer functionality. It ensures that messages can be delivered between signaling points across the SS7 network regardless of whether they are directly connected. It includes such capabilities as node addressing, routing, alternate routing, and congestion control.

Signaling Connection Control Part (SCCP)

ISDN User Part (ISUP)

ISUP user part defines the messages and protocol used in the establishment and tear down of voice and data calls over the public switched network (PSN), and to manage the trunk network on which they rely. Despite its name, ISUP is used for both ISDN and non–ISDN calls. In the North American version of SS7, ISUP messages rely exclusively on MTP to transport messages between concerned nodes.

Transaction Capabilities Application Part (TCAP)

TCAP defines the messages and protocol used to communicate between applications (deployed as subsystems) in nodes. It is used for database services such as calling card, 800, and AIN as well as switch-to-switch services including repeat dialing and call return. Because TCAP messages must be delivered to individual applications within the nodes they address, they use the SCCP for transport.

Operations, Maintenance, and Administration Part (OMAP)

OMAP defines messages and protocol designed to assist administrators of the SS7 network. To date, the most fully developed and deployed of these capabilities are procedures for validating network routing tables and for diagnosing link troubles. OMAP includes messages that use both the MTP and SCCP for routing.

GSM Specifications

2009-08-09T10:18:00.001-07:00

GSM Specifications:

Before looking at the GSM specifications, it is important to understand the following basic terms:

bandwidth —the range of a channel's limits; the broader the bandwidth, the faster data can be sent
bits per second (bps) —a single on-off pulse of data; eight bits are equivalent to one byte
frequency —the number of cycles per unit of time; frequency is measured in hertz (Hz)
kilo (k) —kilo is the designation for 1,000; the abbreviation kbps represents 1,000 bits per second
megahertz (MHz) —1,000,000 hertz (cycles per second)
milliseconds (ms) —one-thousandth of a second
watt (W) —a measure of power of a transmitter

Specifications for different personal communication services (PCS) systems vary among the different PCS networks. Listed below is a description of the specifications and characteristics for GSM.

frequency band —The frequency range specified for GSM is 1,850 to 1,990 MHz (mobile station to base station).
duplex distance —The duplex distance is 80 MHz. Duplex distance is the distance between the uplink and downlink frequencies. A channel has two frequencies, 80 MHz apart.
channel separation —The separation between adjacent carrier frequencies. In GSM, this is 200 kHz.
modulation —Modulation is the process of sending a signal by changing the characteristics of a carrier frequency. This is done in GSM via Gaussian minimum shift keying (GMSK).
transmission rate —GSM is a digital system with an over-the-air bit rate of 270 kbps.
access method —GSM utilizes the time division multiple access (TDMA) concept. TDMA is a technique in which several different calls may share the same carrier. Each call is assigned a particular time slot.
speech coder —GSM uses linear predictive coding (LPC). The purpose of LPC is to reduce the bit rate. The LPC provides parameters for a filter that mimics the vocal tract. The signal passes through this filter, leaving behind a residual signal. Speech is encoded at 13 kbps.

GSM Subscriber Services

There are two basic types of services offered through GSM: telephony (also referred to as teleservices) and data (also referred to as bearer services). Telephony services are mainly voice services that provide subscribers with the complete capability (including necessary terminal equipment) to communicate with other subscribers. Data services provide the capacity necessary to transmit appropriate data signals between two access points creating an interface to the network. In addition to normal telephony and emergency calling, the following subscriber services are supported by GSM:

dual-tone multifrequency (DTMF) —DTMF is a tone signaling scheme often used for various control purposes via the telephone network, such as remote control of an answering machine. GSM supports full-originating DTMF.
facsimile group III —GSM supports CCITT Group 3 facsimile. As standard fax machines are designed to be connected to a telephone using analog signals, a special fax converter connected to the exchange is used in the GSM system. This enables a GSM–connected fax to communicate with any analog fax in the network.
short message services —A convenient facility of the GSM network is the short message service. A message consisting of a maximum of 160 alphanumeric characters can be sent to or from a mobile station. This service can be viewed as an advanced form of alphanumeric paging with a number of advantages. If the subscriber's mobile unit is powered off or has left the coverage area, the message is stored and offered back to the subscriber when the mobile is powered on or has reentered the coverage area of the network. This function ensures that the message will be received.
cell broadcast —A variation of the short message service is the cell broadcast facility. A message of a maximum of 93 characters can be broadcast to all mobile subscribers in a certain geographic area. Typical applications include traffic congestion warnings and reports on accidents.
voice mail —This service is actually an answering machine within the network, which is controlled by the subscriber. Calls can be forwarded to the subscriber's voice-mail box and the subscriber checks for messages via a personal security code.
fax mail —With this service, the subscriber can receive fax messages at any fax machine. The messages are stored in a service center from which they can be retrieved by the subscriber via a personal security code to the desired fax number.

Supplementary Services

GSM supports a comprehensive set of supplementary services that can complement and support both telephony and data services. Supplementary services are defined by GSM and are characterized as revenue-generating features. A partial listing of supplementary services follows.

call forwarding —This service gives the subscriber the ability to forward incoming calls to another number if the called mobile unit is not reachable, if it is busy, if there is no reply, or if call forwarding is allowed unconditionally.
barring of outgoing calls —This service makes it possible for a mobile subscriber to prevent all outgoing calls.
barring of incoming calls —This function allows the subscriber to prevent incoming calls. The following two conditions for incoming call barring exist: baring of all incoming calls and barring of incoming calls when roaming outside the home PLMN.
advice of charge (AoC) —The AoC service provides the mobile subscriber with an estimate of the call charges. There are two types of AoC information: one that provides the subscriber with an estimate of the bill and one that can be used for immediate charging purposes. AoC for data calls is provided on the basis of time measurements.
call hold —This service enables the subscriber to interrupt an ongoing call and then subsequently reestablish the call. The call hold service is only applicable to normal telephony.
call waiting —This service enables the mobile subscriber to be notified of an incoming call during a conversation. The subscriber can answer, reject, or ignore the incoming call. Call waiting is applicable to all GSM telecommunications services using a circuit-switched connection.
multiparty service —The multiparty service enables a mobile subscriber to establish a multiparty conversation—that is, a simultaneous conversation between three and six subscribers. This service is only applicable to normal telephony.
calling line identification presentation/restriction —These services supply the called party with the integrated services digital network (ISDN) number of the calling party. The restriction service enables the calling party to restrict the presentation. The restriction overrides the presentation.
closed user groups (CUGs) —CUGs are generally comparable to a PBX. They are a group of subscribers who are capable of only calling themselves and certain numbers.

GSM Overview

2009-08-09T10:17:00.001-07:00

Global system for mobile communication (GSM) is a globally accepted standard for digital cellular communication. GSM is the name of a standardization group established in 1982 to create a common European mobile telephone standard that would formulate specifications for a pan-European mobile cellular radio system operating at 900 MHz. It is estimated that many countries outside of Europe will join the GSM partnership.

Cellular is one of the fastest growing and most demanding telecommunications applications. Throughout the evolution of cellular telecommunications, various systems have been developed without the benefit of standardized specifications. This presented many problems directly related to compatibility, especially with the development of digital radio technology. The GSM standard is intended to address these problems.

From 1982 to 1985 discussions were held to decide between building an analog or digital system. After multiple field tests, a digital system was adopted for GSM. The next task was to decide between a narrow or broadband solution. In May 1987, the narrowband time division multiple access (TDMA) solution was chosen.

GSM provides recommendations, not requirements. The GSM specifications define the functions and interface requirements in detail but do not address the hardware. The reason for this is to limit the designers as little as possible but still to make it possible for the operators to buy equipment from different suppliers. The GSM network is divided into three major systems: the switching system (SS), the base station system (BSS), and the operation and support system (OSS).

GSM Architecture:

The Switching System:

The switching system (SS) is responsible for performing call processing and subscriber-related functions. The switching system includes the following functional units.

home location register (HLR) —The HLR is a database used for storage and management of subscriptions. The HLR is considered the most important database, as it stores permanent data about subscribers, including a subscriber's service profile, location information, and activity status. When an individual buys a subscription from one of the PCS operators, he or she is registered in the HLR of that operator.
mobile services switching center (MSC) —The MSC performs the telephony switching functions of the system. It controls calls to and from other telephone and data systems. It also performs such functions as toll ticketing, network interfacing, common channel signaling, and others.
visitor location register (VLR) —The VLR is a database that contains temporary information about subscribers that is needed by the MSC in order to service visiting subscribers. The VLR is always integrated with the MSC. When a mobile station roams into a new MSC area, the VLR connected to that MSC will request data about the mobile station from the HLR. Later, if the mobile station makes a call, the VLR will have the information needed for call setup without having to interrogate the HLR each time.
authentication center (AUC) —A unit called the AUC provides authentication and encryption parameters that verify the user's identity and ensure the confidentiality of each call. The AUC protects network operators from different types of fraud found in today's cellular world.
equipment identity register (EIR) —The EIR is a database that contains information about the identity of mobile equipment that prevents calls from stolen, unauthorized, or defective mobile stations. The AUC and EIR are implemented as stand-alone nodes or as a combined AUC/EIR node.

The Base Station System (BSS):

All radio-related functions are performed in the BSS, which consists of base station controllers (BSCs) and the base transceiver stations (BTSs).

BSC —The BSC provides all the control functions and physical links between the MSC and BTS. It is a high-capacity switch that provides functions such as handover, cell configuration data, and control of radio frequency (RF) power levels in base transceiver stations. A number of BSCs are served by an MSC.
BTS —The BTS handles the radio interface to the mobile station. The BTS is the radio equipment (transceivers and antennas) needed to service each cell in the network. A group of BTSs are controlled by a BSC.

The Operation and Support System:

The operations and maintenance center (OMC) is connected to all equipment in the switching system and to the BSC. The implementation of OMC is called the operation and support system (OSS). The OSS is the functional entity from which the network operator monitors and controls the system. The purpose of OSS is to offer the customer cost-effective support for centralized, regional, and local operational and maintenance activities that are required for a GSM network. An important function of OSS is to provide a network overview and support the maintenance activities of different operation and maintenance organizations.

Additional Functional Elements:

Other functional elements shown in Figure 2 are as follows:

message center (MXE) —The MXE is a node that provides integrated voice, fax, and data messaging. Specifically, the MXE handles short message service, cell broadcast, voice mail, fax mail, e-mail, and notification.
mobile service node (MSN) —The MSN is the node that handles the mobile intelligent network (IN) services.
gateway mobile services switching center (GMSC) —A gateway is a node used to interconnect two networks. The gateway is often implemented in an MSC. The MSC is then referred to as the GMSC.
GSM interworking unit (GIWU) —The GIWU consists of both hardware and software that provides an interface to various networks for data communications. Through the GIWU, users can alternate between speech and data during the same call. The GIWU hardware equipment is physically located at the MSC/VLR.

SMS SMS/EMS

2009-07-06T01:52:00.001-07:00

WHAT IS SMS / EMS

SMS stands for short message service. Simply put, it is a method of communication that sends text between cell phones, or from a PC or handheld to a cell phone. The "short" part refers to the maximum size of the text messages: 160 characters (letters, numbers or symbols in the Latin alphabet). For other alphabets, such as Chinese, the maximum SMS size is 70 characters. But how do SMS messages actually get to your phone?

If you have read How Cell Phones Work, you can actually see what is happening. Even if you are not talking on your cell phone, your phone is constantly sending and receiving information. It is talking to its cell phone tower over a pathway called a control channel. The reason for this chatter is so that the cell phone system knows which cell your phone is in, and so that your phone can change cells as you move around. Every so often, your phone and the tower will exchange a packet of data that lets both of them know that everything is OK.

Your phone also uses the control channel for call setup. When someone tries to call you, the tower sends your phone a message over the control channel that tells your phone to play its ring tone. The tower also gives your phone a pair of voice channel frequencies to use for the call. The control channel also provides the pathway for SMS messages. When a friend sends you an SMS message, the message flows through the SMSC, then to the tower, and the tower sends the message to your phone as a little packet of data on the control channel. In the same way, when you send a message, your phone sends it to the tower on the control channel and it goes from the tower to the SMSC and from there to its destination. The actual data format for the message includes things like the length of the message, a time stamp, the destination phone number, the format, etc. For a complete byte-by-byte breakdown of the message format, see this page.

History of sms

SMS was created during the late 1980s to work with a digital technology called GSM (global system for mobile communications), which is the basis for most modern cell phones. The Norwegian engineers who invented it wanted a very simple messaging system that worked when users' mobile phones were turned off or out of signal range. Most sources agree that the first SMS message was sent in the UK in 1992.As SMS was born in Europe, it's not surprising that it took a little longer to make its way to the United States . Even today, texting enjoys much greater popularity in Europe , though its stateside use is on the rise. A July 2005 study found that 37 percent of U.S. mobile phone owners had sent or received at least one text message in the previous month

WHY SMS IS ONLY 160 CHARACTERS ?

SMS was designed to deliver short bursts of data such as numerical pages. To avoid overloading the system with more than the standard forward-and-response operation, the inventors of SMS agreed on a 160-character maximum message size.But the 160-character limit is not absolute. Length limitations may vary depending on the network, phone model and wireless carrier. Some phones don't allow you to keep typing once the 160-character limit is reached. You must send your message before continuing. However, some services will automatically break any message you send into chunks of 160 characters or less. So, you can type and send a long message, but it will be delivered as several messages.

MMS stands for MULTIMEDIA MESAGING SERVICE. It is the evolution of Short Message Service(SMS) (SMS is a text-only messaging technology for mobile networks). With MMS, a mobile device is no longer confined to text-only messages. It can send and receive multimedia messages such as graphics, video and audio clips, and so on. It has been designed to work with mobile packet data services such as GPRS and 1x. MMS-enabled mobile phones enable subscribers to compose and send messages with one or more multimedia parts. Multimedia parts may include text,image,audio and video. These content types should conform to the MMS Standards.

For example your phone can send an MPEG-4 video in AVI format, but the other party who is receiving the MMS may not be able to interpret it. To avoid this, all mobiles should follow the standards defined by OMA.

MMS was originally developed within the Third-Generation Partnership Program (3GPP), a standards organization focused on standards for the GPRS/GSM networks. Since then, MMS has been deployed world-wide and across both GSM/GPRS and CDMA networks. MMS has also been standardized within the Third-Generation Partnership Program 2 (3GPP2), a standards organization focused on specifications for the CDMA networks. . Mobile phones with built-in or attached cameras, or with built-in MP3 players are very likely to also have an MMS messaging client -- a software program that interacts with the mobile subscriber to compose, address, send, receive, and view MMS messages.

EMS, also referred to as Enhanced Messaging Service. EMS is simply SMS with additional payload capabilities is a cross-industry collaboration between Ericsson, Motorola, Siemens and Alcatel, among others. EMS is a halfway house between SMS and MMS, providing some of the features of MMS. EMS is a technology that is designed to work with existing networks, but may ultimately be made obsolete by MMS.

EMS, an application-level extension to SMS for phones available on GSM, GPRS,TDMA and CDMA networks. An EMS enabled mobile phone can send and receive messages that have special text formatting ,animations, pictures, icons, sound effects and special ring tones.EMS messages that are sent to devices that do not support it will be displayed as SMS transmissions.