Monday, December 28, 2009

SMS Web Menu Interface

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.

Wednesday, September 30, 2009

SCTP Headers

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

Important

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 ValueChunk Code
1Invalid Stream Identifier
2Missing Mandatory Parameter
3Stale Cookie Error
4Out of Resource
5Unresolvable Address
6Unrecognized Chunk Type
7Invalid Mandatory Parameter
8Unrecognized Parameters
9No User Data
10Cookie 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 NameStatusType Value
IPv4 AddressOptional5
IPv6 AddressOptional6
Cookie PreservativeOptional9
Host Name AddressOptional11
Supported Address TypesOptional12
Reserved for ECN CapableOptional32768

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 NameStatusType Value
IPv4 AddressOptional5
IPv6 AddressOptional6
State CookieMandatory7
Unrecognized ParametersOptional8
Cookie PreservativeOptional9
Host Name AddressOptional11
Reserved for ECN CapableOptional32768

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

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.

Note

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.

Sunday, August 9, 2009

SS7 Details

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.

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 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.