IP Multimedia Subsystem
The IP Multimedia Subsystem (IMS) is an architectural framework for delivering internet protocol (IP) multimedia to mobile users. It was originally designed by the wireless standards body 3rd Generation Partnership Project (3GPP), and is part of the vision for evolving mobile networks beyond GSM. Its original formulation (3GPP R5) represented an approach to delivering "Internet services" over GPRS. This vision was later updated by 3GPP, 3GPP2 and TISPAN by requiring support of networks other than GPRS, such as Wireless LAN, CDMA2000 and fixed line.
To ease the integration with the Internet, IMS as far as possible uses IETF (i.e. Internet) protocols such as Session Initiation Protocol (SIP). According to the 3GPP[1], IMS is not intended to standardise applications itself but to aid the access of multimedia and voice applications across wireless and wireline terminals, i.e. aid a form of fixed mobile convergence (FMC). This is done by having a horizontal control layer that isolates the access network from the service layer. Services need not have their own control functions, as the control layer is a common horizontal layer.
Alternative and overlapping technologies for access and provision of services across wired and wireless networks depend on the actual requirements, and include combinations of Generic Access Network, soft switches and "naked" SIP. This makes the business use of IMS less appealing. It is easier to sell services than to sell the virtues of "integrated services". But, services for IMS have not been prolific.
Since IMS was conceived years ago, it is becoming increasingly easier to access content and contacts using mechanisms outside the control of traditional wireless/fixed operators, and so those operators are likely to reconsider their strategies[2]. Although it is expected that eventually IP will be available on all mobile phones and operators, it is not clear how much of the 3GPP/3GPP2/TISPAN IMS as it exists today will be deployed. "Early IMS" might be used in IMS implementations that do not yet support all "Full IMS" requirements, although it's not clearly defined what differences there might be (IPv4 support instead of IPv6 is often mentioned).
Global Worldwide Office in Orlando Florida - US. Branch Office in Anaheim California - US.
Selasa, 10 Juni 2008
Signalling Connection Control Part (SCCP)
Signalling Connection Control Part
SS7 protocol suite
Layer
Protocols
Application
INAP, MAP, IS-41...
TCAP, CAP, ISUP, ...
Transport
SCCP
Network
MTP Level 3
Data link
MTP Level 2
...
Physical
MTP Level 1
...
The Signalling Connection Control Part (SCCP) is a transport layer protocol which provides extended routing, flow control, segmentation, connection-orientation, and error correction facilities in Signaling System 7 telecommunications networks. SCCP relies on the services of MTP for basic routing and error detection.
Contents[hide]
1 Published specification
2 Routing facilities beyond MTP-3
3 Classes of service
3.1 Class 0: Basic connectionless
3.2 Class 1: Sequenced connectionless
3.3 Class 2: Basic connection-oriented
3.4 Class 3: Flow control connection oriented
4 Transport over IP Networks
5 References
6 External links
//
[edit] Published specification
The base SCCP specification is defined by the ITU-T, in recommendations Q.711 to Q.714, with additional information to implementors provided by Q.715 and Q.716. There are, however, regional variations defined by local standards bodies. In the United States, ANSI publishes its modifications to Q.713 as ANSI T1.112 or JT-Q.711 to JT-Q.714, whilst in Europe ETSI publishes ETSI EN 300 009, which documents its modifications to the ITU-T specification.
[edit] Routing facilities beyond MTP-3
Although MTP-3 provides routing capabilities based upon the Point Code, SCCP allows routing using a Point Code and Subsystem number or a Global Title.
A Point Code is used to address a particular node on the network, whilst a Subsystem number addresses a specific application available on that node. SCCP employs a process called Global Title Translation (which is similar to DNS resolution in IP networks) in order to determine Point Codes from Global Titles so as to instruct MTP-3 on where to route messages.
SCCP messages contain parameters which describe the type of addressing used, and how the message should be routed:
Address Indicator
Subsystem indicator: The address includes a Subsystem Number
Point Code indicator: The address includes a Point Code
Global title indicator
No Global Title
Global Title includes Translation Type (TT), Numbering Plan Indiciator (NPI) and Type of Number (TON)
Global Title includes Translation Type only
Routing indicator
Route using Global Title only
Route using Point Code/Subsystem number
Address Indicator Coding
Address Indicator coded as national (the Address Indicator is treated as international if not specified)
[edit] Classes of service
SCCP provides 5 classes of service to its applications:
Class 0: Basic connectionless
Class 1: Sequenced connectionless
Class 2: Basic connection-oriented
Class 3: Flow control connection oriented
Class 4: Error recovery and flow control connection oriented
The connectionless protocol classes provide the capabilities needed to transfer one Network Service Data Unit (NSDU) in the "data" field of an XUDT, LUDT or UDT message. When one connectionless message is not sufficient to convey the user data contained in one NSDU, a segmenting/reassembly function for protocol classes 0 and 1 is provided. In this case, the SCCP at the originating node or in a relay node provides segmentation of the information into multiple segments prior to transfer in the "data" field of XUDT (or as a network option LUDT) messages. At the destination node, the NSDU is reassembled.
The connection-oriented protocol classes (protocol classes 2 and 3) provide the means to set up signalling connections in order to exchange a number of related NSDUs. The connection-oriented protocol classes also provide a segmenting and reassembling capability. If an NSDU is longer than 255 octets, it is split into multiple segments at the originating node, prior to transfer in the "data" field of DT messages. Each segment is less than or equal to 255 octets. At the destination node, the NSDU is reassembled.[1]
[edit] Class 0: Basic connectionless
The SCCP Class 0 service is the most basic of SCCP transports. Network Service Data Units passed by higher layers to the SCCP in the originating node are delivered by the SCCP to higher layers in the destination node. They are transferred independently of each other. Therefore, they may be delivered to the SCCP user out-of-sequence. Thus, this protocol class corresponds to a pure connectionless network service. As a connectionless protocol, no transport-level dialog is established between the sender and the receiver.
[edit] Class 1: Sequenced connectionless
SCCP Class 1 builds on the capabilities of Class 0, with the addition of a sequence control parameter in the NSDU which allows the SCCP User to instruct the SCCP that a given stream of messages should be delivered in sequence. Therefore, Protocol Class 1 corresponds to an enhanced connectionless service with in-sequence delivery.
[edit] Class 2: Basic connection-oriented
SCCP Class 2 provides the facilities of Class 1, but also allows for an entity to establish a two-way dialog with another entity using SCCP.
[edit] Class 3: Flow control connection oriented
Class 3 service builds upon Class 2, but also allows for expedited (urgent) messages to be sent and received, and for errors in sequencing (segment re-assembly) to be detected and for SCCP to restart a connection should this occur.
[edit] Transport over IP Networks
In the SIGTRAN suite of protocols, there are two primary methods of transporting SCCP applications across Internet Protocol networks: SCCP can be transported directly using the MTP level 3 User Adaptation protocol (M3UA), a protocol which provides support for users of MTP-3—including SCCP. Alternatively, SCCP applications can operate over the SCCP User Adaptation protocol (SUA) which is a form of modified SCCP designed specifically for use in IP networking.
SS7 protocol suite
Layer
Protocols
Application
INAP, MAP, IS-41...
TCAP, CAP, ISUP, ...
Transport
SCCP
Network
MTP Level 3
Data link
MTP Level 2
...
Physical
MTP Level 1
...
The Signalling Connection Control Part (SCCP) is a transport layer protocol which provides extended routing, flow control, segmentation, connection-orientation, and error correction facilities in Signaling System 7 telecommunications networks. SCCP relies on the services of MTP for basic routing and error detection.
Contents[hide]
1 Published specification
2 Routing facilities beyond MTP-3
3 Classes of service
3.1 Class 0: Basic connectionless
3.2 Class 1: Sequenced connectionless
3.3 Class 2: Basic connection-oriented
3.4 Class 3: Flow control connection oriented
4 Transport over IP Networks
5 References
6 External links
//
[edit] Published specification
The base SCCP specification is defined by the ITU-T, in recommendations Q.711 to Q.714, with additional information to implementors provided by Q.715 and Q.716. There are, however, regional variations defined by local standards bodies. In the United States, ANSI publishes its modifications to Q.713 as ANSI T1.112 or JT-Q.711 to JT-Q.714, whilst in Europe ETSI publishes ETSI EN 300 009, which documents its modifications to the ITU-T specification.
[edit] Routing facilities beyond MTP-3
Although MTP-3 provides routing capabilities based upon the Point Code, SCCP allows routing using a Point Code and Subsystem number or a Global Title.
A Point Code is used to address a particular node on the network, whilst a Subsystem number addresses a specific application available on that node. SCCP employs a process called Global Title Translation (which is similar to DNS resolution in IP networks) in order to determine Point Codes from Global Titles so as to instruct MTP-3 on where to route messages.
SCCP messages contain parameters which describe the type of addressing used, and how the message should be routed:
Address Indicator
Subsystem indicator: The address includes a Subsystem Number
Point Code indicator: The address includes a Point Code
Global title indicator
No Global Title
Global Title includes Translation Type (TT), Numbering Plan Indiciator (NPI) and Type of Number (TON)
Global Title includes Translation Type only
Routing indicator
Route using Global Title only
Route using Point Code/Subsystem number
Address Indicator Coding
Address Indicator coded as national (the Address Indicator is treated as international if not specified)
[edit] Classes of service
SCCP provides 5 classes of service to its applications:
Class 0: Basic connectionless
Class 1: Sequenced connectionless
Class 2: Basic connection-oriented
Class 3: Flow control connection oriented
Class 4: Error recovery and flow control connection oriented
The connectionless protocol classes provide the capabilities needed to transfer one Network Service Data Unit (NSDU) in the "data" field of an XUDT, LUDT or UDT message. When one connectionless message is not sufficient to convey the user data contained in one NSDU, a segmenting/reassembly function for protocol classes 0 and 1 is provided. In this case, the SCCP at the originating node or in a relay node provides segmentation of the information into multiple segments prior to transfer in the "data" field of XUDT (or as a network option LUDT) messages. At the destination node, the NSDU is reassembled.
The connection-oriented protocol classes (protocol classes 2 and 3) provide the means to set up signalling connections in order to exchange a number of related NSDUs. The connection-oriented protocol classes also provide a segmenting and reassembling capability. If an NSDU is longer than 255 octets, it is split into multiple segments at the originating node, prior to transfer in the "data" field of DT messages. Each segment is less than or equal to 255 octets. At the destination node, the NSDU is reassembled.[1]
[edit] Class 0: Basic connectionless
The SCCP Class 0 service is the most basic of SCCP transports. Network Service Data Units passed by higher layers to the SCCP in the originating node are delivered by the SCCP to higher layers in the destination node. They are transferred independently of each other. Therefore, they may be delivered to the SCCP user out-of-sequence. Thus, this protocol class corresponds to a pure connectionless network service. As a connectionless protocol, no transport-level dialog is established between the sender and the receiver.
[edit] Class 1: Sequenced connectionless
SCCP Class 1 builds on the capabilities of Class 0, with the addition of a sequence control parameter in the NSDU which allows the SCCP User to instruct the SCCP that a given stream of messages should be delivered in sequence. Therefore, Protocol Class 1 corresponds to an enhanced connectionless service with in-sequence delivery.
[edit] Class 2: Basic connection-oriented
SCCP Class 2 provides the facilities of Class 1, but also allows for an entity to establish a two-way dialog with another entity using SCCP.
[edit] Class 3: Flow control connection oriented
Class 3 service builds upon Class 2, but also allows for expedited (urgent) messages to be sent and received, and for errors in sequencing (segment re-assembly) to be detected and for SCCP to restart a connection should this occur.
[edit] Transport over IP Networks
In the SIGTRAN suite of protocols, there are two primary methods of transporting SCCP applications across Internet Protocol networks: SCCP can be transported directly using the MTP level 3 User Adaptation protocol (M3UA), a protocol which provides support for users of MTP-3—including SCCP. Alternatively, SCCP applications can operate over the SCCP User Adaptation protocol (SUA) which is a form of modified SCCP designed specifically for use in IP networking.
Camel Application Part (CAP)
Camel Application Part
From Wikipedia, the free encyclopedia
Jump to: navigation, search
Please help improve this article or section by expanding it.Further information might be found on the talk page or at requests for expansion. (January 2007)
SS7 protocol suite
Layer
Protocols
Application
INAP, MAP, IS-41...
TCAP, CAP, ISUP, ...
Transport
SCCP
Network
MTP Level 3
Data link
MTP Level 2
...
Physical
MTP Level 1
...
The CAMEL Application Part (CAP) is a signalling protocol used in the Intelligent Network (IN) architecture. CAP is a Remote Operations Service Element (ROSE) user protocol, and as such is layered on top of the Transaction Capabilities Application Part (TCAP) of the SS#7 protocol suite. CAP is based on a subset of the ETSI Core and allows for the implementation of carrier-grade, value added services such as unified messaging, prepaid, fraud control and Freephone in both the GSM voice and GPRS data networks. CAMEL is a means of adding intelligent applications to mobile (rather than fixed) networks. It builds upon established practices in the fixed line telephony business that are generally classed under the heading of (Intelligent Network Application Part) or INAP CS-2 protocol.[1]
[edit] Protocol specification
The CAMEL Application Part (CAP) portable software provides mechanisms to support operator services beyond the standard GSM services for subscribers roaming within or outside the Home PLMN (HPLMN). The CAP product extends the IN framework to GSM/3G networks for implementing IN-based services within GSM/3G networks.
CAMEL is used when the subscriber is roaming between networks, allowing the home network to monitor and control calls made by the subscriber. CAMEL provides services such as prepaid roaming services, fraud control, special numbers (e.g., 123 for voicemail that works everywhere) and closed user groups (e.g., office extension numbers that work everywhere).
As with CAMEL, CAP has been defined in 4 phases, each of which has an accompanying specification that builds upon the previous phase. Each CAP phase provides the message set and procedures needed to support the corresponding CAMEL phase requirements, as defined in 3GPP TS 22.078 (service aspects) and 3GPP TS 23.078 (technical realization).
The definition of the protocol may be considered to be split into 3 sections:
the definition of the Single Association Control Function (SACF)/Multiple Association Control Function (MACF) rules for the protocol, defined within the prose of the specification;
the definition of the operations transferred between entities, defined using Abstract Syntax Notation One (ASN.1);
the definition of the actions taken at each entity, defined by means of state transition diagrams.
From Wikipedia, the free encyclopedia
Jump to: navigation, search
Please help improve this article or section by expanding it.Further information might be found on the talk page or at requests for expansion. (January 2007)
SS7 protocol suite
Layer
Protocols
Application
INAP, MAP, IS-41...
TCAP, CAP, ISUP, ...
Transport
SCCP
Network
MTP Level 3
Data link
MTP Level 2
...
Physical
MTP Level 1
...
The CAMEL Application Part (CAP) is a signalling protocol used in the Intelligent Network (IN) architecture. CAP is a Remote Operations Service Element (ROSE) user protocol, and as such is layered on top of the Transaction Capabilities Application Part (TCAP) of the SS#7 protocol suite. CAP is based on a subset of the ETSI Core and allows for the implementation of carrier-grade, value added services such as unified messaging, prepaid, fraud control and Freephone in both the GSM voice and GPRS data networks. CAMEL is a means of adding intelligent applications to mobile (rather than fixed) networks. It builds upon established practices in the fixed line telephony business that are generally classed under the heading of (Intelligent Network Application Part) or INAP CS-2 protocol.[1]
[edit] Protocol specification
The CAMEL Application Part (CAP) portable software provides mechanisms to support operator services beyond the standard GSM services for subscribers roaming within or outside the Home PLMN (HPLMN). The CAP product extends the IN framework to GSM/3G networks for implementing IN-based services within GSM/3G networks.
CAMEL is used when the subscriber is roaming between networks, allowing the home network to monitor and control calls made by the subscriber. CAMEL provides services such as prepaid roaming services, fraud control, special numbers (e.g., 123 for voicemail that works everywhere) and closed user groups (e.g., office extension numbers that work everywhere).
As with CAMEL, CAP has been defined in 4 phases, each of which has an accompanying specification that builds upon the previous phase. Each CAP phase provides the message set and procedures needed to support the corresponding CAMEL phase requirements, as defined in 3GPP TS 22.078 (service aspects) and 3GPP TS 23.078 (technical realization).
The definition of the protocol may be considered to be split into 3 sections:
the definition of the Single Association Control Function (SACF)/Multiple Association Control Function (MACF) rules for the protocol, defined within the prose of the specification;
the definition of the operations transferred between entities, defined using Abstract Syntax Notation One (ASN.1);
the definition of the actions taken at each entity, defined by means of state transition diagrams.
Transaction Capabilities Application Part (TCAP)
Transaction Capabilities Application Part
Layer
Protocols
Application
INAP, MAP, IS-41...
TCAP, CAP, ISUP, ...
Transport
SCCP
Network
MTP Level 3
Data link
MTP Level 2
...
Physical
MTP Level 1
...
Transaction Capabilities Application Part, from ITU-T recommendations Q.771-Q.775 or ANSI T1.114 is a protocol for Signalling System 7 networks. Its primary purpose is to facilitate multiple concurrent dialogs between the same sub-systems on the same machines, using Transaction IDs to differentiate these, similar to the way TCP ports facilitate multiplexing connections between the same IP addresses on the Internet.
TCAP is used to transport INAP in Intelligent Networks and MAP in mobile phone networks.
TCAP messages are sent over the wire between machines. TCAP primitives are sent between the application and the local TCAP stack, all TCAP messages are primitives but there are primitives that are not messages, i.e. some are only transferred inside the local machine. A TCAP primitive is made up of one or more TCAP components.
A TCAP primitive may be one of the following types:
Unidirectional
A single primitive with no subsequent primitives. Sometimes referred to as a Notice.
Begin
Start a dialog, further primitives will follow.
Continue
Send a subsequent primitive on an existing dialog, further primitives will follow.
End
The last primitive on an existing dialog, Close an existing dialog.
Abort
An error has caused the dialog to close.
Cancel
The invoke timer has expired without a response being received (this is a primitive but not a message)
A Begin primitive has an, up to 4 bytes, Originating Transaction ID, Continues also have a Destination Transaction ID, Ends and Aborts only have a Destination Transaction ID. Each primitive have both optional component and dialogue portions. Component portion for the unidirecitonal primitive is mandatory.
The dialogue portion carries dialogue or unidialogue control PDUs. For MAP and INAP, dialogue PDU is used which performs establishment and release of dialogues for the application context provided in the primitives. Following primitives are defined for the dialogue PDU:
AARQ
Dialogue request. For MAP and INAP, AARQ is sent in the Begin primitive with the Invoke component in general, with the application context of MAP/INAP operation's package.
AARE
Dialogue response. Sent in response to AARQ in either Continue or End primitives.
ABRT
Dialogue abort.
Each TCAP component may be one of the following types:
Invoke
A new operation is being requested, this may or may not solicit a response
Return Result Last
A final response to an Invoke
Return Result Not Last
A response to an Invoke, further responses will be sent
Return Error
An error occurred
Reject
Component is rejected for some reason like duplicate invocation, unrecognized linked id, unrecognized operation or mistyped argument
Invoke components have a signed 7 bit InvokeID which is present in all the other components to identify which invoke they relate to.
TCAP can be regarded as light weight implementation of the OSI defined ROSE, Remote Operations Services Element protocol
[edit] Transaction ID
The transaction ID is a TCAP reference for a set of TCAP operations that are performed within a single dialog. When machine A starts a TCAP dialog with another machine B, the machine A sends a Begin message to machine B. This Begin message contains an Originating Transaction ID, which is the Transaction ID reference for A. When the machine B replies to A with a Continue message it includes A's Transaction ID as the Destination Transaction ID. Furthermore B includes its own Transaction ID as the Originating Transaction ID.
As the TCAP dialog goes on each Continue message includes the Transaction ID of the destination machine as the Destination Transaction ID and the Transaction ID of the originating machine as the Originating Transaction ID. When any of the machines wants to close the dialog it sends an End message or an Abort message to the other machine. This message contains the Destination Transaction ID only.
[edit] Invoke ID
Invoke ID is a TCAP reference for a specific TCAP operation.
Layer
Protocols
Application
INAP, MAP, IS-41...
TCAP, CAP, ISUP, ...
Transport
SCCP
Network
MTP Level 3
Data link
MTP Level 2
...
Physical
MTP Level 1
...
Transaction Capabilities Application Part, from ITU-T recommendations Q.771-Q.775 or ANSI T1.114 is a protocol for Signalling System 7 networks. Its primary purpose is to facilitate multiple concurrent dialogs between the same sub-systems on the same machines, using Transaction IDs to differentiate these, similar to the way TCP ports facilitate multiplexing connections between the same IP addresses on the Internet.
TCAP is used to transport INAP in Intelligent Networks and MAP in mobile phone networks.
TCAP messages are sent over the wire between machines. TCAP primitives are sent between the application and the local TCAP stack, all TCAP messages are primitives but there are primitives that are not messages, i.e. some are only transferred inside the local machine. A TCAP primitive is made up of one or more TCAP components.
A TCAP primitive may be one of the following types:
Unidirectional
A single primitive with no subsequent primitives. Sometimes referred to as a Notice.
Begin
Start a dialog, further primitives will follow.
Continue
Send a subsequent primitive on an existing dialog, further primitives will follow.
End
The last primitive on an existing dialog, Close an existing dialog.
Abort
An error has caused the dialog to close.
Cancel
The invoke timer has expired without a response being received (this is a primitive but not a message)
A Begin primitive has an, up to 4 bytes, Originating Transaction ID, Continues also have a Destination Transaction ID, Ends and Aborts only have a Destination Transaction ID. Each primitive have both optional component and dialogue portions. Component portion for the unidirecitonal primitive is mandatory.
The dialogue portion carries dialogue or unidialogue control PDUs. For MAP and INAP, dialogue PDU is used which performs establishment and release of dialogues for the application context provided in the primitives. Following primitives are defined for the dialogue PDU:
AARQ
Dialogue request. For MAP and INAP, AARQ is sent in the Begin primitive with the Invoke component in general, with the application context of MAP/INAP operation's package.
AARE
Dialogue response. Sent in response to AARQ in either Continue or End primitives.
ABRT
Dialogue abort.
Each TCAP component may be one of the following types:
Invoke
A new operation is being requested, this may or may not solicit a response
Return Result Last
A final response to an Invoke
Return Result Not Last
A response to an Invoke, further responses will be sent
Return Error
An error occurred
Reject
Component is rejected for some reason like duplicate invocation, unrecognized linked id, unrecognized operation or mistyped argument
Invoke components have a signed 7 bit InvokeID which is present in all the other components to identify which invoke they relate to.
TCAP can be regarded as light weight implementation of the OSI defined ROSE, Remote Operations Services Element protocol
[edit] Transaction ID
The transaction ID is a TCAP reference for a set of TCAP operations that are performed within a single dialog. When machine A starts a TCAP dialog with another machine B, the machine A sends a Begin message to machine B. This Begin message contains an Originating Transaction ID, which is the Transaction ID reference for A. When the machine B replies to A with a Continue message it includes A's Transaction ID as the Destination Transaction ID. Furthermore B includes its own Transaction ID as the Originating Transaction ID.
As the TCAP dialog goes on each Continue message includes the Transaction ID of the destination machine as the Destination Transaction ID and the Transaction ID of the originating machine as the Originating Transaction ID. When any of the machines wants to close the dialog it sends an End message or an Abort message to the other machine. This message contains the Destination Transaction ID only.
[edit] Invoke ID
Invoke ID is a TCAP reference for a specific TCAP operation.
The Mobile Application Part (MAP)
Mobile Application Part
Layer
Protocols
Application
INAP, MAP, IS-41...
TCAP, CAP, ISUP, ...
Transport
SCCP
Network
MTP Level 3
Data link
MTP Level 2
...
Physical
MTP Level 1
...
The Mobile Application Part (MAP) is a SS7 protocol which provides an application layer for the various nodes in GSM and UMTS mobile core networks and GPRS core networks to communicate with each other in order to provide services to mobile phone users. The Mobile Application Part is the application-layer protocol used to access the Home Location Register, Visitor Location Register, Mobile Switching Center, Equipment Identity Register, Authentication Centre, Short message service center and Serving GPRS Support Node.
Layer
Protocols
Application
INAP, MAP, IS-41...
TCAP, CAP, ISUP, ...
Transport
SCCP
Network
MTP Level 3
Data link
MTP Level 2
...
Physical
MTP Level 1
...
The Mobile Application Part (MAP) is a SS7 protocol which provides an application layer for the various nodes in GSM and UMTS mobile core networks and GPRS core networks to communicate with each other in order to provide services to mobile phone users. The Mobile Application Part is the application-layer protocol used to access the Home Location Register, Visitor Location Register, Mobile Switching Center, Equipment Identity Register, Authentication Centre, Short message service center and Serving GPRS Support Node.
The Intelligent Network Application Part (INAP)
INAP
Layer
Protocols
Application
INAP, MAP, IS-41...
TCAP, CAP, ISUP, ...
Transport
SCCP
Network
MTP Level 3
Data link
MTP Level 2
...
Physical
MTP Level 1
...
The Intelligent Network Application Part (INAP) is a signalling protocol used in the intelligent network architecture. It is part of the SS7 protocol suite, typically layered on top of TCAP.It can also be termed as logic for controlling telecommunication services migrated from traditional switching points to computer based service independent platform[1]
The ITU defines several "capability levels" for this protocol, starting with Capability Set 1 (CS-1). A typical application for the IN is a Number Translation service. For example, in the United Kingdom, 0800 numbers are freephone numbers and are translated to a geographic number using an IN platform. The Telephone exchanges decode the 0800 numbers to an IN trigger and the exchange connects to the IN.
The Telephone exchange uses TCAP, SCCP and INAP and in IN terms is a Service Switching Point. It sends an INAP Initial Detection Point (IDP) message to the Service Control Point. The SCP returns an INAP Connect message, which contains a geographic number to forward the call to.
INAP messages are defined using ASN.1 encoding. SCCP is used for the routing. Extended form of INAP is Customised Applications for Mobile Enhanced Logic. TCAP is used to separate the transactions into discrete units.
Retrieved from "http://en.wikipedia.org/wiki/INAP"
Layer
Protocols
Application
INAP, MAP, IS-41...
TCAP, CAP, ISUP, ...
Transport
SCCP
Network
MTP Level 3
Data link
MTP Level 2
...
Physical
MTP Level 1
...
The Intelligent Network Application Part (INAP) is a signalling protocol used in the intelligent network architecture. It is part of the SS7 protocol suite, typically layered on top of TCAP.It can also be termed as logic for controlling telecommunication services migrated from traditional switching points to computer based service independent platform[1]
The ITU defines several "capability levels" for this protocol, starting with Capability Set 1 (CS-1). A typical application for the IN is a Number Translation service. For example, in the United Kingdom, 0800 numbers are freephone numbers and are translated to a geographic number using an IN platform. The Telephone exchanges decode the 0800 numbers to an IN trigger and the exchange connects to the IN.
The Telephone exchange uses TCAP, SCCP and INAP and in IN terms is a Service Switching Point. It sends an INAP Initial Detection Point (IDP) message to the Service Control Point. The SCP returns an INAP Connect message, which contains a geographic number to forward the call to.
INAP messages are defined using ASN.1 encoding. SCCP is used for the routing. Extended form of INAP is Customised Applications for Mobile Enhanced Logic. TCAP is used to separate the transactions into discrete units.
Retrieved from "http://en.wikipedia.org/wiki/INAP"
SS7 protocol
SS7 protocol suite
Layer
Protocols
Application
INAP, MAP, IS-41...
TCAP, CAP, ISUP, ...
Transport
SCCP
Network
MTP Level 3
Data link
MTP Level 2
...
Physical
MTP Level 1
...
The SS7 protocol stack borrows partially from the OSI Model of a packetized digital protocol stack. OSI layers 1 to 3 are provided by the Message Transfer Part (MTP) of the SS7 protocol; for circuit related signalling, such as the Telephone User Part (TUP) or the ISDN User Part (ISUP), the User Part provides layers 4 to 7, whereas for non-circuit related signalling the Signalling Connection and Control Part (SCCP) provides layer 4 capabilities to the SCCP user. The Transaction Capabilities Application Part (TCAP) is the primary SCCP User in the Core Network, using SCCP in connectionless mode. SCCP in connection oriented mode provides the transport layer for air interface protocols such as BSSAP and RANAP. TCAP provides transaction capabilities to its Users (TC-Users), such as the Mobile Application Part, the Intelligent Network Application Part and the CAMEL Application Part.
The MTP covers the transport protocols including network interface, information transfer, message handling and routing to the higher levels. SCCP is a sub-part of other L4 protocols, together with MTP 3 it can be called the Network Service Part (NSP), it provides end-to-end addressing and routing, connectionless messages (UDTs), and management services for the other L4 user parts. TUP is a link-by-link signaling system used to connect calls. ISUP is the key user part, providing a circuit-based protocol to establish, maintain, and end the connections for calls. TCAP is used to create database queries and invoke advanced network functionality, or links to intelligent networks (INAP), mobile services (MAP).
[edit] MAP Signaling
In mobile cellular telephony networks like GSM and UMTS the SS7 application MAP is used. Voice connections are Circuit Switched (CS) and data connections are Packet Switched (PS) applications.
Some of the GSM/UMTS Core Switched interfaces in the Mobile Switching Center (MSC) transported over SS7 include the following:
B -> VLR (uses MAP/B). Most MSCs are associated with a Visitor Location Register (VLR), making the B interface "internal".
D -> HLR (uses MAP/D) for attaching to the CS network and location update
E -> MSC (uses MAP/E) for inter-MSC handover
F -> EIR (uses MAP/F) for equipment identity check
H -> SMS-G (uses MAP/H) for Short Message Service (SMS) over CS
There are also several GSM/UMTS PS interfaces in the Serving GPRS Support Node (SGSN) transported over SS7:
Gr -> HLR for attaching to the PS network and location update
Gd -> SMS-C for SMS over PS
Gs -> MSC for combined CS+PS signaling over PS
Ge -> Charging for Customised Applications for Mobile networks Enhanced Logic (CAMEL) prepaid charging
Gf -> EIR for equipment identity check
[edit] SS7 in the IMS Future
The tone or style of this article or section may not be appropriate for Wikipedia.Specific concerns may be found on the talk page. See Wikipedia's guide to writing better articles for suggestions.(March 2008)
Users invested heavily in SS7 architecture in the late 20th century, and the evolution of SS7-based signaling network infrastructure to Session Initiation Protocol-based (SIP-based) signaling infrastructure, or IMS networking, does not involve just changing from SS7 to SIP protocols and procedures, it requires a fundamental shift in the network's design to accommodate more types of services, devices and customer preferences. This expensive change is difficult for investors to accept in a short time. Here are some important considerations as operators are making the transition:
SS7 is likely to remain the principal signaling technology for years to come. Operators continue to invest billions of dollars each year to maintain and expand their existing SS7 networks and to develop enhanced voice and data services that protect against commoditization of POTS voice service. In fact, almost all of the past decade's value-added services including mobility, voicemail, wireless prepaid services, Short Message Service (SMS), and number portability, exist because of SS7 signaling. As a result, at least a subset of carriers will continue to squeeze as much as they can out of their existing signaling networks and investments.
Operators are at different stages in their IP migration paths and require tailored solutions. These typically combine several "bridging technologies," which help transition between SIP-based, next-generation networks and existing networks.
The first step in the transition is to simply replace the SS7 transport with IP transport using SIGTRAN protocols. This protects, to the maximum extent possible, the existing investment in the SS7 technology base and huge cost savings can be reaped in certain situations due to the vast difference in transport cost of IP compared to the traditional SS7 TDM. Network elements such as Signaling Gateways (SG), Signaling Transfer Points (STP), or Edge STPs (ESTP) provide the signaling translation from SS7 to SIGTRAN. For more information on SIGTRAN, refer to RFC 2719: Architectural Framework for Signaling Transport.
Beyond the simple replacement of transport, we enter the realm of gateways that convert network addresses, protocol content, and even one kind of protocol to another. One example solution, a SIP-SS7 gateway, bridges the 2G and 3G networks at the signaling layer. It expands the services and applications available to SS7 and SIP subscribers and enables a larger subscriber base to access those services, driving additional revenue for the carrier.
The signaling control layer is a cornerstone of IMS, largely because of the value SS7 signaling has provided to generic dial-tone networks over the past 20 years. Looking ahead, the SIP signaling intensity of multimedia networks will increase dramatically, and experts predict the number and size of SIP signaling messages will increase over SS7 by an order of magnitude.
Another bridging solution, an SMS gateway, integrates messaging capabilities between SIP networks and existing mobile networks. It enables transferring of SS7-based SMS messages to SIP and short message peer-to-peer protocol (SMPP) networks, expanding the potential carrier subscriber base significantly.
Layer
Protocols
Application
INAP, MAP, IS-41...
TCAP, CAP, ISUP, ...
Transport
SCCP
Network
MTP Level 3
Data link
MTP Level 2
...
Physical
MTP Level 1
...
The SS7 protocol stack borrows partially from the OSI Model of a packetized digital protocol stack. OSI layers 1 to 3 are provided by the Message Transfer Part (MTP) of the SS7 protocol; for circuit related signalling, such as the Telephone User Part (TUP) or the ISDN User Part (ISUP), the User Part provides layers 4 to 7, whereas for non-circuit related signalling the Signalling Connection and Control Part (SCCP) provides layer 4 capabilities to the SCCP user. The Transaction Capabilities Application Part (TCAP) is the primary SCCP User in the Core Network, using SCCP in connectionless mode. SCCP in connection oriented mode provides the transport layer for air interface protocols such as BSSAP and RANAP. TCAP provides transaction capabilities to its Users (TC-Users), such as the Mobile Application Part, the Intelligent Network Application Part and the CAMEL Application Part.
The MTP covers the transport protocols including network interface, information transfer, message handling and routing to the higher levels. SCCP is a sub-part of other L4 protocols, together with MTP 3 it can be called the Network Service Part (NSP), it provides end-to-end addressing and routing, connectionless messages (UDTs), and management services for the other L4 user parts. TUP is a link-by-link signaling system used to connect calls. ISUP is the key user part, providing a circuit-based protocol to establish, maintain, and end the connections for calls. TCAP is used to create database queries and invoke advanced network functionality, or links to intelligent networks (INAP), mobile services (MAP).
[edit] MAP Signaling
In mobile cellular telephony networks like GSM and UMTS the SS7 application MAP is used. Voice connections are Circuit Switched (CS) and data connections are Packet Switched (PS) applications.
Some of the GSM/UMTS Core Switched interfaces in the Mobile Switching Center (MSC) transported over SS7 include the following:
B -> VLR (uses MAP/B). Most MSCs are associated with a Visitor Location Register (VLR), making the B interface "internal".
D -> HLR (uses MAP/D) for attaching to the CS network and location update
E -> MSC (uses MAP/E) for inter-MSC handover
F -> EIR (uses MAP/F) for equipment identity check
H -> SMS-G (uses MAP/H) for Short Message Service (SMS) over CS
There are also several GSM/UMTS PS interfaces in the Serving GPRS Support Node (SGSN) transported over SS7:
Gr -> HLR for attaching to the PS network and location update
Gd -> SMS-C for SMS over PS
Gs -> MSC for combined CS+PS signaling over PS
Ge -> Charging for Customised Applications for Mobile networks Enhanced Logic (CAMEL) prepaid charging
Gf -> EIR for equipment identity check
[edit] SS7 in the IMS Future
The tone or style of this article or section may not be appropriate for Wikipedia.Specific concerns may be found on the talk page. See Wikipedia's guide to writing better articles for suggestions.(March 2008)
Users invested heavily in SS7 architecture in the late 20th century, and the evolution of SS7-based signaling network infrastructure to Session Initiation Protocol-based (SIP-based) signaling infrastructure, or IMS networking, does not involve just changing from SS7 to SIP protocols and procedures, it requires a fundamental shift in the network's design to accommodate more types of services, devices and customer preferences. This expensive change is difficult for investors to accept in a short time. Here are some important considerations as operators are making the transition:
SS7 is likely to remain the principal signaling technology for years to come. Operators continue to invest billions of dollars each year to maintain and expand their existing SS7 networks and to develop enhanced voice and data services that protect against commoditization of POTS voice service. In fact, almost all of the past decade's value-added services including mobility, voicemail, wireless prepaid services, Short Message Service (SMS), and number portability, exist because of SS7 signaling. As a result, at least a subset of carriers will continue to squeeze as much as they can out of their existing signaling networks and investments.
Operators are at different stages in their IP migration paths and require tailored solutions. These typically combine several "bridging technologies," which help transition between SIP-based, next-generation networks and existing networks.
The first step in the transition is to simply replace the SS7 transport with IP transport using SIGTRAN protocols. This protects, to the maximum extent possible, the existing investment in the SS7 technology base and huge cost savings can be reaped in certain situations due to the vast difference in transport cost of IP compared to the traditional SS7 TDM. Network elements such as Signaling Gateways (SG), Signaling Transfer Points (STP), or Edge STPs (ESTP) provide the signaling translation from SS7 to SIGTRAN. For more information on SIGTRAN, refer to RFC 2719: Architectural Framework for Signaling Transport.
Beyond the simple replacement of transport, we enter the realm of gateways that convert network addresses, protocol content, and even one kind of protocol to another. One example solution, a SIP-SS7 gateway, bridges the 2G and 3G networks at the signaling layer. It expands the services and applications available to SS7 and SIP subscribers and enables a larger subscriber base to access those services, driving additional revenue for the carrier.
The signaling control layer is a cornerstone of IMS, largely because of the value SS7 signaling has provided to generic dial-tone networks over the past 20 years. Looking ahead, the SIP signaling intensity of multimedia networks will increase dramatically, and experts predict the number and size of SIP signaling messages will increase over SS7 by an order of magnitude.
Another bridging solution, an SMS gateway, integrates messaging capabilities between SIP networks and existing mobile networks. It enables transferring of SS7-based SMS messages to SIP and short message peer-to-peer protocol (SMPP) networks, expanding the potential carrier subscriber base significantly.
Intelligent network (IN)
Intelligent network
The Intelligent Network, typically stated as its acronym IN, is a network architecture intended both for fixed as well as mobile telecom networks. It allows operators to differentiate themselves by providing value-added services in addition to the standard telecom services such as PSTN, ISDN and GSM services on mobile phones.
In IN, the intelligence is provided by network nodes owned by telecom operators, as opposed to solutions based on intelligence in the telephone equipment, or in Internet servers provided by any part.
IN is based on the Signaling System #7 (SS7) protocol between telephone network switching centers and other network nodes owned by network operators.
Examples of IN services
Examples of such services are:
Televoting
Call screening
Telephone number portability
Toll free calls
Prepaid calling
Account card calling
Virtual private networks
Centrex service (Virtual PBX)
Private-number plans (with numbers remaining unpublished in directories)
Universal Personal Telecommunication service (a universal personal telephone number)
Mass-calling service
Prefix free dialing from cellphones abroad
Seamless MMS message access from abroad.
Reverse charging
Home Area Discount
Freephone
Premium Rate calls
Location Based Routing
[edit] History and key concepts
The IN concepts, architecture and protocols were originally developed as standards by the ITU-T which is the standardization committee of the International Telecommunication Union. The primary aim of the IN was to enhance the core telephony services offered by traditional telecommunications networks, which usually amounted to making and receiving voice calls, sometimes with call divert. This core would then provide a basis upon which operators could build services in addition to those already present on a standard telephone exchange. Examples of the kind of custom services.
A complete description of the IN emerged in a set of ITU-T standards named Q.1210 to Q.1219, or Capability Set One (CS-1) as they became known. The standards defined a complete architecture including the architectural view, state machines, physical implementation and protocols. They were universally embraced by telecom suppliers and operators, although many variants were derived for use in different parts of the world (see Variants below).
Following the success of CS-1, further enhancements followed in the form of CS-2. Although the standards were completed, they were not as widely implemented as CS-1, partly because of the increasing power of the variants, but also partly because they addressed issues which pushed traditional telephone exchanges to their limits.
The primus motor behind the development of the IN system was the need for a more flexible way of adding sophisticated services to the existing network. Before IN was developed, all new feature and/or services that was to be added had to be implemented directly in the core switch systems. This made for very long release cycles as the bug hunting and testing had to be extensive and thorough to prevent the network from failing. With the advent of IN, most of these services (such as toll free numbers and geographical number portability) was moved out of the core switch systems and into self serving nodes (IN), thus creating a modular and more secure network that allowed the services providers themselves to develop variations and value-added services to their network without submitting a request to the core switch manufacturer and wait for the long development process. The initial use of IN technology was for number translation services, e.g. when translating toll free numbers to regular PSTN numbers. But much more complex services have since been built on IN, such as Custom Local Area Signaling Services (CLASS) and prepaid telephone calls.
[edit] SS7 Architecture
The main concepts(functional view) surrounding IN services or architecture are connected with SS7 architecture:
Service Switching Function (SSF) or Service Switching Point (SSP) This is co-located with the telephone exchange itself, and acts as the trigger point for further services to be invoked during a call. The SSP implements the Basic Call State Machine (BCSM) which is a Finite state machine that represents an abstract view of a call from beginning to end (off hook; dialling; answer; no answer; busy; hang up etc). As each state is traversed, the exchange encounters Detection Points (DPs) at which the SSP may invoke a query to the SCP to wait for further instructions on how to proceed. This query is usually called a trigger. Trigger criteria are defined by the operator and might include the subscriber calling number or the dialled number. The SSF is responsible for entertaining calls requiring value added services.
Service Control Function (SCF) or Service Control Point (SCP) This is a separate set of platforms that receive queries from the SSP. The SCP contains service logic which implements the behaviour desired by the operator, i.e., the services. During service logic processing, additional data required to process the call may be obtained from the SDF. The logic on the SCP is created using the SCE.
Service Data Function (SDF) or Service Data Point (SDP) This is a database that contains additional subscriber data, or other data required to process a call. For example, the subscribers prepaid credit which is remaining may be an item stored in the SDF to be queried in real time during the call. The SDF may be a separate platform, or is sometimes co-located with the SCP.
Service Creation Environment (SCE) This is the development environment used to create the services present on the SCP. Although the standards permit any type of environment, it is fairly rare to see low level languages like C used. Instead, proprietary graphical languages have been used to enable telecom engineers to create services directly. The languages usually belong to 4G languages, the user can use Graphical Interface to manipulate between different functions to formulate a service.
Specialized Resource Function (SRF) or Intelligent Peripheral (IP) This is a node which can connect to both the SSP and the SCP and delivers additional special resources into the call, mostly related to voice data, for example play voice announcements or collect DTMF tones from the user.
[edit] Protocols
The core elements described above use standard protocols to communicate with each other. The use of standard protocols allows different manufacturers to concentrate on different parts of the architecture and be confident that they will all work together in any combination.
The interfaces between the SSP and the SCP are SS7 based and may look familiar to those familiar with TCP/IP protocols. In fact, the SS7 protocols implement much of the OSI seven-layer model. This means that the IN standards only had to define the application layer which was called the Intelligent Networks Application Part or INAP. The INAP messages are encoded using ASN.1.
The interface between the SCP and the SDP is defined in the standards to be an X.500 Directory Access Protocol or DAP. However, a more lightweight interface called LDAP has emerged from the IETF which is considerably simpler to implement, so many SCPs have implemented that instead.
[edit] Variants
The core CS-1 specifications were adopted and extended by other standards bodies. European flavours were developed by ETSI, American flavours were developed by ANSI and Japanese variants also exist. The main reasons for producing variants in each region was to ensure interoperability between equipment manufactured and deployed locally (for example different versions of the underlying SS7 protocols exist between the regions).
However, new functionality was also added which meant that variants diverged from each other and the main ITU-T standard. The biggest variant was called Customised Applications for Mobile networks Enhanced Logic, or CAMEL for short. This allowed for extensions to be made for the mobile phone environment, and allowed mobile phone operators to offer the same IN services to subscribers while they are roaming as they receive in the home network.
CAMEL has become a major standard in its own right and is currently maintained by 3GPP. The last major release of the standard was CAMEL phase 4. It is the only IN standard currently being actively worked on.
The Advanced Intelligent Network (AIN) is the variant of Intelligent Network developed for North America by Bellcore (now Telcordia). The standardization of the AIN was performed by Bellcore on behalf of the major US operators. The original goal of AIN was AIN 1.0 which was specified in the early 1990s (AIN Release 1, Bellcore SR-NWT-002247, 1993). AIN 1.0 proved technically infeasabile to implement, which lead to the definition of simplified AIN 0.1 and AIN 0.2 specifications. In North America the SR-3511 (originally known as 1129+) and GR-1129-CORE protocols are used to link switches with the IN systems such as Service Control Points (SCPs) or Service Nodes. SR-3511 is a TCP/IP based protocol which directly connects the SCP and Service Node. GR-1129-CORE is an ISDN based protocol which connects the SCP to the Service Node via the SSP.
[edit] Future
While active development in IN standardization has declined in recent years, there are many systems deployed across the world which use this technology. The architecture has proved to be not only stable, but also a continuing source of revenue with new services added all the time. Manufacturers continue to support the equipment and obsolescence is not an issue.
Nevertheless, new technologies and architectures are emerging, especially in the area of VoIP and SIP. More attention is being paid to the use of APIs in preference to protocols like INAP and new standards have emerged in the form of JAIN and Parlay. From a technical view, the SCE is beginning to move away from its proprietary graphical origins and is moving towards a Java application server environment.
The Intelligent Network, typically stated as its acronym IN, is a network architecture intended both for fixed as well as mobile telecom networks. It allows operators to differentiate themselves by providing value-added services in addition to the standard telecom services such as PSTN, ISDN and GSM services on mobile phones.
In IN, the intelligence is provided by network nodes owned by telecom operators, as opposed to solutions based on intelligence in the telephone equipment, or in Internet servers provided by any part.
IN is based on the Signaling System #7 (SS7) protocol between telephone network switching centers and other network nodes owned by network operators.
Examples of IN services
Examples of such services are:
Televoting
Call screening
Telephone number portability
Toll free calls
Prepaid calling
Account card calling
Virtual private networks
Centrex service (Virtual PBX)
Private-number plans (with numbers remaining unpublished in directories)
Universal Personal Telecommunication service (a universal personal telephone number)
Mass-calling service
Prefix free dialing from cellphones abroad
Seamless MMS message access from abroad.
Reverse charging
Home Area Discount
Freephone
Premium Rate calls
Location Based Routing
[edit] History and key concepts
The IN concepts, architecture and protocols were originally developed as standards by the ITU-T which is the standardization committee of the International Telecommunication Union. The primary aim of the IN was to enhance the core telephony services offered by traditional telecommunications networks, which usually amounted to making and receiving voice calls, sometimes with call divert. This core would then provide a basis upon which operators could build services in addition to those already present on a standard telephone exchange. Examples of the kind of custom services.
A complete description of the IN emerged in a set of ITU-T standards named Q.1210 to Q.1219, or Capability Set One (CS-1) as they became known. The standards defined a complete architecture including the architectural view, state machines, physical implementation and protocols. They were universally embraced by telecom suppliers and operators, although many variants were derived for use in different parts of the world (see Variants below).
Following the success of CS-1, further enhancements followed in the form of CS-2. Although the standards were completed, they were not as widely implemented as CS-1, partly because of the increasing power of the variants, but also partly because they addressed issues which pushed traditional telephone exchanges to their limits.
The primus motor behind the development of the IN system was the need for a more flexible way of adding sophisticated services to the existing network. Before IN was developed, all new feature and/or services that was to be added had to be implemented directly in the core switch systems. This made for very long release cycles as the bug hunting and testing had to be extensive and thorough to prevent the network from failing. With the advent of IN, most of these services (such as toll free numbers and geographical number portability) was moved out of the core switch systems and into self serving nodes (IN), thus creating a modular and more secure network that allowed the services providers themselves to develop variations and value-added services to their network without submitting a request to the core switch manufacturer and wait for the long development process. The initial use of IN technology was for number translation services, e.g. when translating toll free numbers to regular PSTN numbers. But much more complex services have since been built on IN, such as Custom Local Area Signaling Services (CLASS) and prepaid telephone calls.
[edit] SS7 Architecture
The main concepts(functional view) surrounding IN services or architecture are connected with SS7 architecture:
Service Switching Function (SSF) or Service Switching Point (SSP) This is co-located with the telephone exchange itself, and acts as the trigger point for further services to be invoked during a call. The SSP implements the Basic Call State Machine (BCSM) which is a Finite state machine that represents an abstract view of a call from beginning to end (off hook; dialling; answer; no answer; busy; hang up etc). As each state is traversed, the exchange encounters Detection Points (DPs) at which the SSP may invoke a query to the SCP to wait for further instructions on how to proceed. This query is usually called a trigger. Trigger criteria are defined by the operator and might include the subscriber calling number or the dialled number. The SSF is responsible for entertaining calls requiring value added services.
Service Control Function (SCF) or Service Control Point (SCP) This is a separate set of platforms that receive queries from the SSP. The SCP contains service logic which implements the behaviour desired by the operator, i.e., the services. During service logic processing, additional data required to process the call may be obtained from the SDF. The logic on the SCP is created using the SCE.
Service Data Function (SDF) or Service Data Point (SDP) This is a database that contains additional subscriber data, or other data required to process a call. For example, the subscribers prepaid credit which is remaining may be an item stored in the SDF to be queried in real time during the call. The SDF may be a separate platform, or is sometimes co-located with the SCP.
Service Creation Environment (SCE) This is the development environment used to create the services present on the SCP. Although the standards permit any type of environment, it is fairly rare to see low level languages like C used. Instead, proprietary graphical languages have been used to enable telecom engineers to create services directly. The languages usually belong to 4G languages, the user can use Graphical Interface to manipulate between different functions to formulate a service.
Specialized Resource Function (SRF) or Intelligent Peripheral (IP) This is a node which can connect to both the SSP and the SCP and delivers additional special resources into the call, mostly related to voice data, for example play voice announcements or collect DTMF tones from the user.
[edit] Protocols
The core elements described above use standard protocols to communicate with each other. The use of standard protocols allows different manufacturers to concentrate on different parts of the architecture and be confident that they will all work together in any combination.
The interfaces between the SSP and the SCP are SS7 based and may look familiar to those familiar with TCP/IP protocols. In fact, the SS7 protocols implement much of the OSI seven-layer model. This means that the IN standards only had to define the application layer which was called the Intelligent Networks Application Part or INAP. The INAP messages are encoded using ASN.1.
The interface between the SCP and the SDP is defined in the standards to be an X.500 Directory Access Protocol or DAP. However, a more lightweight interface called LDAP has emerged from the IETF which is considerably simpler to implement, so many SCPs have implemented that instead.
[edit] Variants
The core CS-1 specifications were adopted and extended by other standards bodies. European flavours were developed by ETSI, American flavours were developed by ANSI and Japanese variants also exist. The main reasons for producing variants in each region was to ensure interoperability between equipment manufactured and deployed locally (for example different versions of the underlying SS7 protocols exist between the regions).
However, new functionality was also added which meant that variants diverged from each other and the main ITU-T standard. The biggest variant was called Customised Applications for Mobile networks Enhanced Logic, or CAMEL for short. This allowed for extensions to be made for the mobile phone environment, and allowed mobile phone operators to offer the same IN services to subscribers while they are roaming as they receive in the home network.
CAMEL has become a major standard in its own right and is currently maintained by 3GPP. The last major release of the standard was CAMEL phase 4. It is the only IN standard currently being actively worked on.
The Advanced Intelligent Network (AIN) is the variant of Intelligent Network developed for North America by Bellcore (now Telcordia). The standardization of the AIN was performed by Bellcore on behalf of the major US operators. The original goal of AIN was AIN 1.0 which was specified in the early 1990s (AIN Release 1, Bellcore SR-NWT-002247, 1993). AIN 1.0 proved technically infeasabile to implement, which lead to the definition of simplified AIN 0.1 and AIN 0.2 specifications. In North America the SR-3511 (originally known as 1129+) and GR-1129-CORE protocols are used to link switches with the IN systems such as Service Control Points (SCPs) or Service Nodes. SR-3511 is a TCP/IP based protocol which directly connects the SCP and Service Node. GR-1129-CORE is an ISDN based protocol which connects the SCP to the Service Node via the SSP.
[edit] Future
While active development in IN standardization has declined in recent years, there are many systems deployed across the world which use this technology. The architecture has proved to be not only stable, but also a continuing source of revenue with new services added all the time. Manufacturers continue to support the equipment and obsolescence is not an issue.
Nevertheless, new technologies and architectures are emerging, especially in the area of VoIP and SIP. More attention is being paid to the use of APIs in preference to protocols like INAP and new standards have emerged in the form of JAIN and Parlay. From a technical view, the SCE is beginning to move away from its proprietary graphical origins and is moving towards a Java application server environment.
Open Service Access or OSA
Open Services Architecture
From Wikipedia, the free encyclopedia
Jump to: navigation, search
The Open Service Access or OSA is part of the 3rd generation mobile telecommunications network or UMTS. OSA describes how Service (systems architecture)services are designed in a UMTS network.
The standards for OSA are being developed as part of the 3rd Generation Partnership Project (3GPP). The standards for OSA are published by ETSI and 3GPP.
The API for OSA is called Parlay, (or Parlay/OSA or OSA/Parlay) as the APIs are developed jointly in collaboration by 3GPP, ETSI, and the Parlay Group. These APIs can be freely downloaded from the web. Sometimes OSA would be misspelled as Open Services Architecture or even confound with Open systems architecture.
From Wikipedia, the free encyclopedia
Jump to: navigation, search
The Open Service Access or OSA is part of the 3rd generation mobile telecommunications network or UMTS. OSA describes how Service (systems architecture)services are designed in a UMTS network.
The standards for OSA are being developed as part of the 3rd Generation Partnership Project (3GPP). The standards for OSA are published by ETSI and 3GPP.
The API for OSA is called Parlay, (or Parlay/OSA or OSA/Parlay) as the APIs are developed jointly in collaboration by 3GPP, ETSI, and the Parlay Group. These APIs can be freely downloaded from the web. Sometimes OSA would be misspelled as Open Services Architecture or even confound with Open systems architecture.
Parlay
Parlay Overview
The Parlay Group is a technical industry consortium (founded 1998) that specifies APIs for the telephone network. These APIs enable the creation of services by organizations both inside and outside of the traditional carrier environment. In fact, it is hoped that services can be created by IT developers, rather than telephony experts.
Important Parlay APIs include: call control, conferencing, user interaction (audio and text messaging), and charging. The APIs are specified in the CORBA Interface definition language and WSDL. The use of CORBA enables remote access between the Parlay gateway and the application code. A set of Java mappings allow the APIs to be invoked locally as well. A major goal of the APIs is to be independent of the underlying telephony network technology (e.g. CDMA vs GSM vs landline SS7).
In 2003 the Parlay Group released a new set of web services called Parlay X. These are a much simpler set of APIs intended to be used by a larger community of developers. The Parlay X web services include Third Party Call Control (3PCC), Location and simple payment. The Parlay X specifications complement the more complex yet powerful Parlay APIs. Parlay X implementations are now (Sept 2004) in commercial service from BT and Sprint.
Parlay work historically stems from the TINA effort. Parlay is somewhat related to JAIN, and is currently (early 2003) completely unrelated to the Service Creation Community.
The Parlay Group works closely with ETSI and 3GPP, the Parlay specifications are co-published by all three bodies. Within 3GPP Parlay is part of Open Services Architecture, so we often use the term Parlay/OSA.
[edit] Parlay Technology
The objective of Parlay/OSA is to provide an API that is independent of the underlying networking technology and of the programming technology used to create new services. As a result the Parlay/OSA APIs are specified in UML. There are then a set of realizations, or mappings, for specific programming environments:
CORBA/IDL
Java
WebService(WSDL)
[edit] Parlay Framework
It is important for a telecom network operator to know that any applications using the Parlay API cannot affect the security or integrity of the network.
The role of the Parlay/OSA Framework is to provide a way for the network to authenticate applications using the Parlay/OSA API. The Framework also allows applications to discover the capabilities of the network, and provides management functions for handling fault and overload situations.
[edit] Parlay APIs
The Parlay service APIs are how an application makes a telephone call, queries the location of a person (or terminal), or charges for the download of a ringtone.
[edit] Implementing Parlay
The Parlay/OSA specifications define an API, they do not say how the API is to be implemented.
The typical Parlay/OSA implementation adds a new network element - the Parlay/OSA Gateway. The Gateway implements the Framework. It may implement the individual service APIs, or may interact with other network elements such as switches to provide individual service capabilities such as call control or location. Some vendors treat the Parlay/OSA Gateway as a stand-alone network element (e.g., the Ericsson NRG, AePONA Causeway, HERIT Parlay/Parlay X Gateway), others include this function in an IN Service Control Point (e.g., the Telcordia OSP).
[edit] Parlay and Web Services
The Parlay X APIs define a set of simple telecom-related Web services. Parlay X Version 1, published in May 2003, defines web services for:
Third Party Call, Network Initiated Third Party Call, Send SMS, Receive SMS, Send Message, Receive Message, Amount Charging, Volume Charging, User Status and Terminal Location
The Parlay Group is a technical industry consortium (founded 1998) that specifies APIs for the telephone network. These APIs enable the creation of services by organizations both inside and outside of the traditional carrier environment. In fact, it is hoped that services can be created by IT developers, rather than telephony experts.
Important Parlay APIs include: call control, conferencing, user interaction (audio and text messaging), and charging. The APIs are specified in the CORBA Interface definition language and WSDL. The use of CORBA enables remote access between the Parlay gateway and the application code. A set of Java mappings allow the APIs to be invoked locally as well. A major goal of the APIs is to be independent of the underlying telephony network technology (e.g. CDMA vs GSM vs landline SS7).
In 2003 the Parlay Group released a new set of web services called Parlay X. These are a much simpler set of APIs intended to be used by a larger community of developers. The Parlay X web services include Third Party Call Control (3PCC), Location and simple payment. The Parlay X specifications complement the more complex yet powerful Parlay APIs. Parlay X implementations are now (Sept 2004) in commercial service from BT and Sprint.
Parlay work historically stems from the TINA effort. Parlay is somewhat related to JAIN, and is currently (early 2003) completely unrelated to the Service Creation Community.
The Parlay Group works closely with ETSI and 3GPP, the Parlay specifications are co-published by all three bodies. Within 3GPP Parlay is part of Open Services Architecture, so we often use the term Parlay/OSA.
[edit] Parlay Technology
The objective of Parlay/OSA is to provide an API that is independent of the underlying networking technology and of the programming technology used to create new services. As a result the Parlay/OSA APIs are specified in UML. There are then a set of realizations, or mappings, for specific programming environments:
CORBA/IDL
Java
WebService(WSDL)
[edit] Parlay Framework
It is important for a telecom network operator to know that any applications using the Parlay API cannot affect the security or integrity of the network.
The role of the Parlay/OSA Framework is to provide a way for the network to authenticate applications using the Parlay/OSA API. The Framework also allows applications to discover the capabilities of the network, and provides management functions for handling fault and overload situations.
[edit] Parlay APIs
The Parlay service APIs are how an application makes a telephone call, queries the location of a person (or terminal), or charges for the download of a ringtone.
[edit] Implementing Parlay
The Parlay/OSA specifications define an API, they do not say how the API is to be implemented.
The typical Parlay/OSA implementation adds a new network element - the Parlay/OSA Gateway. The Gateway implements the Framework. It may implement the individual service APIs, or may interact with other network elements such as switches to provide individual service capabilities such as call control or location. Some vendors treat the Parlay/OSA Gateway as a stand-alone network element (e.g., the Ericsson NRG, AePONA Causeway, HERIT Parlay/Parlay X Gateway), others include this function in an IN Service Control Point (e.g., the Telcordia OSP).
[edit] Parlay and Web Services
The Parlay X APIs define a set of simple telecom-related Web services. Parlay X Version 1, published in May 2003, defines web services for:
Third Party Call, Network Initiated Third Party Call, Send SMS, Receive SMS, Send Message, Receive Message, Amount Charging, Volume Charging, User Status and Terminal Location
Java APIs for Integrated Networks (JAIN)
Java APIs for Integrated Networks (JAIN) is an activity within the Java Community Process, developing APIs for the creation of telephony (voice and data) services. Originally, JAIN stood for Java APIs for Intelligent Network. The name was later changed to Java APIs for Integrated Networks to reflect the widening scope of the project. The JAIN activity consists of a number of "Expert Groups", each developing a single API specification.
JAIN is part of a general trend to open up service creation in the telephony network so that, by analogy with the Internet, openness should result in a growing number of participants creating services, in turn creating more demand and better, more targeted services.
A major goal of the JAIN APIs is to abstract the underlying network, so that services can be developed independent of network technology, be it traditional PSTN or Next Generation Network.
The JAIN effort has produced around 20 APIs, in various stages of standardization, ranging from Java APIs for specific network protocols, such as SIP and TCAP, to more abstract APIs such as for call control and charging, and even including a non-Java effort for describing telephony services in XML.
There is overlap between JAIN and Parlay/OSA because both address similar problem spaces. However, as originally conceived, JAIN focused on APIs that would make it easier for network operators to develop their own services within the framework of Intelligent Network (IN) protocols. As a consequence, the first JAIN APIs focused on methods for building and interpreting SS7 messages and it was only later that JAIN turned its attention to higher-level methods for call control. Meanwhile, at about the same time JAIN was getting off the ground, work on Parlay began with a focus on APIs to enable development of network services by non-operator third parties.
From around 2001 to 2003, there was an effort to harmonize the not yet standardized JAIN APIs for call control with the comparable and by then standardized Parlay APIs. A number of difficulties were encountered, but perhaps the most serious was not technical but procedural. The Java Community Process requires that a reference implementation be built for every standardized Java API. Parlay does not have this requirement. Not surprisingly, given the effort that would have been needed to build a reference implementation of JAIN call control, the standards community decided, implicitly if not explicitly, that the Parlay call control APIs were adequate and work on JAIN call control faded off. Nonetheless, the work on JAIN call control did have an important impact on Parlay since it helped to drive the definition of an agreed-upon mapping of Parlay to the Java language.
JAIN is part of a general trend to open up service creation in the telephony network so that, by analogy with the Internet, openness should result in a growing number of participants creating services, in turn creating more demand and better, more targeted services.
A major goal of the JAIN APIs is to abstract the underlying network, so that services can be developed independent of network technology, be it traditional PSTN or Next Generation Network.
The JAIN effort has produced around 20 APIs, in various stages of standardization, ranging from Java APIs for specific network protocols, such as SIP and TCAP, to more abstract APIs such as for call control and charging, and even including a non-Java effort for describing telephony services in XML.
There is overlap between JAIN and Parlay/OSA because both address similar problem spaces. However, as originally conceived, JAIN focused on APIs that would make it easier for network operators to develop their own services within the framework of Intelligent Network (IN) protocols. As a consequence, the first JAIN APIs focused on methods for building and interpreting SS7 messages and it was only later that JAIN turned its attention to higher-level methods for call control. Meanwhile, at about the same time JAIN was getting off the ground, work on Parlay began with a focus on APIs to enable development of network services by non-operator third parties.
From around 2001 to 2003, there was an effort to harmonize the not yet standardized JAIN APIs for call control with the comparable and by then standardized Parlay APIs. A number of difficulties were encountered, but perhaps the most serious was not technical but procedural. The Java Community Process requires that a reference implementation be built for every standardized Java API. Parlay does not have this requirement. Not surprisingly, given the effort that would have been needed to build a reference implementation of JAIN call control, the standards community decided, implicitly if not explicitly, that the Parlay call control APIs were adequate and work on JAIN call control faded off. Nonetheless, the work on JAIN call control did have an important impact on Parlay since it helped to drive the definition of an agreed-upon mapping of Parlay to the Java language.
Java Service Logic Execution Environment (JSLEE)
Java Service Logic Execution Environment (JSLEE)
A Service Logic Execution Environment (SLEE) is a well known concept in the telecommunications industry. A SLEE is a high throughput, low latency event processing application environment. JSLEE is the Java standard for SLEE.
JSLEE is designed to allow implementations of the standard to meet the stringent requirements of communications applications, such as network signaling applications. The JSLEE specification is designed so that implementations can achieve scalability and availability through clustering architectures.
JSLEE is an industry standard aimed at portable communications applications, i.e. a communications application can be written once and run on many different implementations of JSLEE. Application portability is made possible by the combination of a programming language API (specified using the Java programming language), an unambiguous technical specification, a Reference Implementation, and a rigorous suite of tests that a vendor must pass before their product is compliant with the JSLEE specification.
JSLEE is the point of integration for multiple network resources and protocols. Applications can use many different external network resources from within the JSLEE environment.
The JSLEE specification allows developers to write robust components as integrates the ACID properties of transactions into the programming model. Components can be composed to solve more complex problems.
JSLEE is also known as JAIN SLEE due to its initial origination under the JAIN program
A Service Logic Execution Environment (SLEE) is a well known concept in the telecommunications industry. A SLEE is a high throughput, low latency event processing application environment. JSLEE is the Java standard for SLEE.
JSLEE is designed to allow implementations of the standard to meet the stringent requirements of communications applications, such as network signaling applications. The JSLEE specification is designed so that implementations can achieve scalability and availability through clustering architectures.
JSLEE is an industry standard aimed at portable communications applications, i.e. a communications application can be written once and run on many different implementations of JSLEE. Application portability is made possible by the combination of a programming language API (specified using the Java programming language), an unambiguous technical specification, a Reference Implementation, and a rigorous suite of tests that a vendor must pass before their product is compliant with the JSLEE specification.
JSLEE is the point of integration for multiple network resources and protocols. Applications can use many different external network resources from within the JSLEE environment.
The JSLEE specification allows developers to write robust components as integrates the ACID properties of transactions into the programming model. Components can be composed to solve more complex problems.
JSLEE is also known as JAIN SLEE due to its initial origination under the JAIN program