SIP Response Codes and Their Meanings

7/7/2014 The Telecom Protocols
http://telecomprotocols.blogspot.in/ 1/51
21st March 2013
SIP responses generated by the UAS or SIP servers.
SIP Response Classes:
1xx - Informational - Indicates the status of call prior to the completion.
2xx - Success - Request has succeeded.
3xx - Redirection - The client should try to complete the request at another server.
4xx - Client Error - The request has failed due to error due to the client. The client may retry.
5xx - Server failure - The request has failed due to server error. request may retry to another server.
6xx - Global failure - the request has failed and can not retry to any server.
1xx --Informational:
100 Trying: This response is used to indicate the next node receives the request and stop the retransmission. This
response is sent if there is delay in sending the final response more the 200ms.
180 Ringing: The response is generated if UA receives the INVITE and started the ringing. It may used to initiate local
ring back.
181 Call is being Forwarded: This response is indication of call is being forwarded to different destination.
182 Call Queued: The called server is overloaded or temporary unavailable. the server sends this status code to
queue the call. When server ready to take the call, it initiates appropriate final response.
183 Call Progress: This response may be used to send extra information for a call which is still being set up.
199 Early Dialog Terminated: Can be used by User Agent Server to indicate to upstream SIP entities (including the
User Agent Client (UAC)) that an early dialog has been terminated.
2xxSuccessful Responses
200 OK: Indicates the request was successful.
202 Accepted: Indicates that the request has been accepted for processing, but the processing has not been
completed.
204 No Notification: Indicates the request was successful, but the corresponding response will not be received.
3xxRedirection Response
300 Multiple Choices: The address resolved to one of several options for the user or client to choose between, which
are listed in the message body or the message's Contact fields.
301 Moved Permanently: The original Request-URI is no longer valid, the new address is given in the Contact
header field, and the client should update any records of the original Request-URI with the new value.
302 Moved Temporarily: The client should try at the address in the Contact field. If an Expires field is present, the
client may cache the result for that period of time.
305 Use Proxy: The Contact field details a proxy that must be used to access the requested destination.
380 Alternative Service: The call failed, but alternatives are detailed in the message body.
4xxClient Failure Responses
400 Bad Request: The request could not be understood due to malformed syntax.
401 Unauthorized: The request requires user authentication. This response is issued by UASs and registrars.
402 Payment Required: Reserved for future use.
403 Forbidden: The server understood the request, but is refusing to fulfill it
404 Not Found: The server has definitive information that the user does not exist at the domain specified in the
Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled
by the recipient of the request.
405 Method Not Allowed: The method specified in the Request-Line is understood, but not allowed for the address
identified by the Request-URI.
406 Not Acceptable: The resource identified by the request is only capable of generating response entities that have
content characteristics but not acceptable according to the Accept header field sent in the request.
407 Proxy Authentication Required: The request requires user authentication. This response is issued by proxys
408 Request Timed Out: Couldn't find the user in time.
409 Conflict: User already registered.
410 Gone: The user existed once, but is not available here any more.
411 Length Required: The server will not accept the request without a valid Content-Length.
412 Conditional Request Failed: The given precondition has not been met.
413 Request Entity Too Large: Request body too large.
414 Request-URI Too Long: The server is refusing to service the request because the Request-URI is longer than
the server is willing to interpret.
415 Unsupported Media Type: Request body in a format not supported.
416 Unsupported URI Scheme: Request-URI is unknown to the server.
417 Unknown Resource-Priority: There was a resource-priority option tag, but no Resource-Priority header.
420 Bad Extension: Bad SIP Protocol Extension used, not understood by the server.
421 Extension Required: The server needs a specific extension not listed in the Supported header.
422 Session Interval Too Small: The received request contains a Session-Expires header field with a duration below
the minimum timer.
423 Interval Too Brief: Expiration time of the resource is too short.
SIP Responses
Dynamic Views template. Template images by chuwy. Powered by Blogger.
Classic Flipcard Magazine Mosaic Sidebar Snapshot Timeslide
The Telecom Protoc
search
424 Bad Location Information: The request's location content was malformed or otherwise unsatisfactory.
428 Use Identity Header: The server policy requires an Identity header, and one has not been provided.
429 Provide Referrer Identity: The server did not receive a valid Referred-By token on the request.
430 Flow Failed: A specific flow to a user agent has failed, although other flows may succeed. This response is
intended for use between proxy devices, and should not be seen by an endpoint (and if it is seen by one, should be
treated as a 400 Bad Request response).
433 Anonymity Disallowed: The request has been rejected because it was anonymous.
436 Bad Identity-Info: The request has an Identity-Info header, and the URI scheme in that header cannot be
dereferenced.
437 Unsupported Certificate: The server was unable to validate a certificate for the domain that signed the request.
438 Invalid Identity Header: The server obtained a valid certificate that the request claimed was used to sign the
request, but was unable to verify that signature.
439 First Hop Lacks Outbound Support: The first outbound proxy the user is attempting to register through does
not support the "outbound" feature of RFC 5626, although the registrar does.
470 Consent Needed: The source of the request did not have the permission of the recipient to make such a request.
480 Temporarily Unavailable: Callee currently unavailable.
481 Call/Transaction Does Not Exist: Server received a request that does not match any dialog or transaction.
482 Loop Detected: Server has detected a loop.
483 Too Many Hops: Max-Forwards header has reached the value '0'.
484 Address Incomplete: Request-URI incomplete.
485 Ambiguous: Request-URI is ambiguous.
486 Busy Here: Callee is busy.
487 Request Terminated: Request has terminated by bye or cancel.
488 Not Acceptable Here: Some aspects of the session description of the Request-URI is not acceptable.
489 Bad Event: The server did not understand an event package specified in an Event header field.
491 Request Pending: Server has some pending request from the same dialog.
493 Undecipherable: Request contains an encrypted MIME body, which recipient can not decrypt.
494 Security Agreement Required: The server has received a request that requires a negotiated security
mechanism, and the response contains a list of suitable security mechanisms for the requester to choose between or a
digest authentication challenge.
5xxServer Failure Responses
500 Server Internal Error: The server could not fulfill the request due to some unexpected condition.
501 Not Implemented: The server does not have the ability to fulfill the request, such as because it does not
recognize the request method. (Compare with 405 Method Not Allowed, where the server recognizes the method but
does not allow or support it.)
502 Bad Gateway: The server is acting as a gateway or proxy, and received an invalid response from a downstream
server while attempting to fulfill the request.
503 Service Unavailable: The server is undergoing maintenance or is temporarily overloaded and so cannot process
the request. A "Retry-After" header field may specify when the client may re attempt its request.
504 Server Time-out: The server attempted to access another server in attempting to process the request, and did
not receive a prompt response.
505 Version Not Supported: The SIP protocol version in the request is not supported by the server
513 Message Too Large: The request message length is longer than the server can process.
580 Precondition Failure: The server is unable or unwilling to meet some constraints specified in the offer.
6xxGlobal Failure Responses
600 Busy Everywhere: All possible destinations are busy. Unlike the 486 response, this response indicates the
destination knows there are no alternative destinations (such as a voicemail server) able to accept the call.
603 Decline: The destination does not wish to participate in the call, or cannot do so, and additionally the client knows
there are no alternative destinations (such as a voicemail server) willing to accept the call.
604 Does Not Exist Anywhere: The server has authoritative information that the requested user does not exist
anywhere.
606 Not Acceptable: The user's agent was contacted successfully but some aspects of the session description such
as the requested media, bandwidth, or addressing style were not acceptable.
Posted 21st March 2013 by Pramod Kumar
Labels: SIP

0
Add a comment
20th March 2013
SIP Servers:
Proxy Servers:
- A stateless proxy server processes each SIP request or response based solely on the message contents. Once the message has been
SIP Methods
parsed, processed, and forwarded or responded to,no information about the message is storedno dialog information is stored. A
stateless proxy never re-transmits a message, and does not use any SIP timers.
- A stateful proxy server keeps track of requests and responses received in the past and uses that information in processing future
requests and responses. For example, a stateful proxy server starts a timer when a request is forwarded. If no response to the
request is received within the timer period, the proxy will
re-transmit the request, relieving the user agent of this task. Also, a stateful proxy can require user agent authentication.
Back-to-Back User Agents (B2BUA):
An B2BUA is a type of SIP device that receives the SIP request, that reformulates the request and send it out as new request.
Response to the request are reformulated and sent back to the UA in opposite direction.
SIP Methods (Request):
1.) INVITE: The INVITE is used to establish the media session between the users. An Invite usually has a message
body containing the media session information as SDP. it also contains other information like QoS and security information. If
INVITE does not contain the media information, the ACK message contains the media information of the UAC.
A media session is considered established when the INVITE, 200 OK, and ACK messages have been exchanged between the UAC
and the UAS. If the media information contained in the ACK is not acceptable, then the called party must send a BYE to cancel the
session, a CANCEL cannot be sent because the session is already established. A UAC that originates an INVITE to establish a
dialog creates a globally unique Call-ID that is used for the duration of the call. A CSeq count is initialized (which need not be set to
1, but must be an integer) and incremented for each new request for the same Call-ID. The To and From headers are populated
with the remote and local addresses. A From tag is included in the INVITE, and the UAS includes a To tag in any responses. A To
tag in a 200 OK response to an INVITE is used in the To header field of the ACK and all future requests within the dialog. The
combination of the To tag, From tag, and Call-ID is the unique identifier for the dialog.
Re-Invite: An INVITE sent for an existing dialog references the same Call-ID as the original INVITE and contains the same To and
From tags. Sometimes called a re-INVITE, the request is used to change the session characteristics or refresh the state of the
dialog. The CSeq command sequence number is incremented so that a UAS can distinguish the re-INVITE from a re-
transmission of the original INVITE.
UPDATE: A re-INVITE must not be sent by a UAC until a final response to the initial INVITE has been received instead, an
UPDATE request can be sent.
An Expires header in an INVITE indicates to the UAS how long the call request is valid. For example, the UAS could leave an
unanswered INVITE request displayed on a screen for the duration of specified in the Expires header. Once a session is established,
the Expires header has no meaning, the expiration of the time does not terminate the media session. Instead, a Session-Expires
header can be used to place a time limit on an established session
2.) REGISTER: REGISTER message used to register the Address of record to Registrar server. The REGISTER method is used by
a user agent to notify a SIP network of its current Contact URI (IP address) and the URI that should have requests routed to this
Contact.The registrar binds the SIP URI of marconi and the IP address of the device in a database that can be used.
----------------------------------------------------------
REGISTER sip:registrar.text.com SIP/2.0
Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bKus1812
Max-Forwards: 70
To: Marconi <sip:marconi@text.com>
From: Marconi <sip:marconi@text.com>
;tag=3431
Call-ID: 1232134@200.201.202.203
CSeq: 1 REGISTER
Contact: sip:marconi@200.201.202.203
Content-Length: 0
--------------------------------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bKus19
To: Marconi <sip:marconi@text.com>;tag=8771
From: Marconi <sip:marconi@text.com>
;tag=3431
Call-ID: 23@200.201.202.203
CSeq: 1 REGISTER
Contact:Marconi <sip:marconi@text.com>;expires=3600
Content-Length: 0
--------------------------------------------------------
The Contact URI is returned along with an expires parameter, which indicates how long the registration is valid, which in this case
is 1 hour (3,600 seconds).
Marconi Registrar Server
=================================
--------------REGISTER--------------------->
<---------------200 OK-----------------------
3.) BYE: The BYE method is used to terminate an established media session. BYE is sent only by user agents
participating in the session, never by proxies or other third parties. It is an end-to-end method, so responses are only
generated by the other user agent.
BYE sip:marconi@test.com SIP/2.0
Via: SIP/2.0/UDP 100.120.100.100:5060;branch=z9hG4bK3145r
Max-Forwards:70
To: Marconi <sip:marconi@test.com>;tag=63104
From: Tela <sip:tesla@text.com>;tag=9341123
Call-ID: 2342324324@100.120.100.100
CSeq: 12 BYE
Content-Length: 0
4.) ACK: The ACK method is used to acknowledge final responses to INVITE requests. Final responses to all other
requests are never acknowledged. Final responses are defined as 2xx, 3xx, 4xx, 5xx, or 6xx class responses. The CSeq
number is never incremented for an ACK, but the CSeq method is changed to ACK. This is so that a UAS can match
the CSeq number of the ACK with the number of the corresponding INVITE.
An ACK may contain an application/sdp message body. This is permitted if the initial INVITE did not contain a SDP
message body. If the INVITE contained a message body, the ACK may not contain a message body. The ACK may not
be used to modify a media description that has already been sent in the initial INVITE; a re-INVITE must be used for this
purpose.
For 2xx responses, the ACK is end-to-end, but for all other final responses it is done on a hop-by-hop basis when
stateful proxies are involved. The end-toend nature of ACKs to 2xx responses allows a message body to be
transported. A hop-by-hop ACK reuses the same branch ID as the INVITE since it is considered part of the same
transaction. An end-to-end ACK uses a different branch ID as it is considered a new transaction.
ACK sip:marconi@text.com SIP/2.0
Via: SIP/2.0/TCP 100.200.102.100:5060;branch=z9hG4bK1234
Max-Forwards:70
To: Marconi <sip:marconi@text.com>;tag=902332
From: Tesla <sip:tesla@test.com>;tag=887823
Call-ID: 123213213213@100.200.102.100
CSeq: 3 ACK
Content-Type: application/sdp
Content-Length: 100
(SDP not shown)
5.) CANCEL: The CANCEL method is used to terminate pending call attempts. It can be generated by either user
agents or proxy servers provided that a 1xx response containing a tag has been received, but no final response has
been received. CANCEL is a hop-by-hop request and receives a response generated by the next stateful element. The
CSeq is not incremented for this method so that proxies and user agents can match the CSeq of the CANCEL with the
CSeq of the pending INVITE to which it corresponds. The branch ID for a CANCEL matches the INVITE that it is
canceling.
CANCEL sip:marconi@text.com SIP/2.0
Via: SIP/2.0/UDP 100.100.122.122:5060;branch=z9hG4bK3134324
Max-Forwards:70
From: Tesla <sip:Tesl@test.com>;tag=034324
Call-ID: 123213@12321321321.com
CSeq: 1 CANCEL
Content-Length: 0
6.) OPTIONS: The OPTIONS method is used to query a user agent or server about its capabilities and discover its
current availability. The response to the request lists the
capabilities of the user agent or server. A proxy never generates an OPTIONS request.
OPTIONS sip:marconi@text.com SIP/2.0
Via: SIP/2.0/UDP 100.200.100.100
;branch=z9hG4bK1834
Max-Forwards:70
From: Tesla <tesla@text.com>
;tag=34
Call-ID: 9352812@100.200.100.100
CSeq: 1 OPTIONS
Content-Length: 0
7.) REFER: The REFER method is used by a user agent to request another user agent to access a URI or URL
resource. The resource is identified by a URI or URL in the required Refer-To header field. When the URI is a sip or
sips URI, the REFER is probably being used to implement a call transfer service. REFER can also used to implement
peer-to-peer call control.
REFER sip:marconi@test.com SIP/2.0
Via SIP/2.0/UDP test.com:5060;branch=z9hG4bK9323249
Max-Forwards: 69
To: <sip:marconi@test.com>;tag=324234
From: Tesla <sip:tesla@test.com>;tag=44432
Call-ID: 3419fak32343243s1A9dkl
CSeq: 5412 REFER
Refer-To: <sip:info@test.com>
Content-Length: 0
8.) SUBSCRIBE: The SUBSCRIBE method is used by a user agent to establish a subscription for the purpose of
receiving notifications (via the NOTIFY method) about a particular event. The subscription request contains an Expires
header field, which indicates the desired duration of the existence of the subscription. After this time period passes, the
subscription is automatically terminated. The subscription can be refreshed by sending another SUBSCRIBE within the
dialog before the expiration time. A server accepting a subscription returns a 200 OK response also obtaining an
Expires header field. There is no UNSUBSCRIBE method used in SIPinstead a SUBSCRIBE with Expires:0 requests
the termination of a subscription and hence the dialog. A terminated subscription (either due to timeout out or a
termination request) will result in a final NOTIFY indicating that the subscription has been terminated.
UA Proxy-Server Presence Agent
====================================
------------Subscribe----------->
-----------Subscribe-------------->
<-----202 Accepted---------------
<-----------------202 Accepted---
<------------------------------------NOTIFY------------------------------
-----------------------200 OK--------------------------------------------->
----------------------------Subscribe-------------------------------------->
<-----------------------------------200 OK-------------------------------
SUBSCRIBE sip:marconi@text.com SIP/2.0
Via SIP/2.0/UDP 200:200:200:201:5060;branch=z9hG4bKABDA ;received=192.0.3.4
Max-Forwards: 69
To: <sip:Ptolemy@rosettastone.org>
From: Tesla <sip:tela@text.com>;tag=1814
Call-ID: 452k59252058234924lk34
CSeq: 3412 SUBSCRIBE
Allow-Events: dialog
Contact: <sip:tesla@200:200:200:201>
Event: dialog
Content-Length: 0
9.) NOTIFY: The NOTIFY method is used by a user agent to convey information about the occurrence of a particular
event. A NOTIFY is always sent within a dialog, when a subscription exists between the subscriber and the notifier. A
NOTIFY request normally receives a 200 OK response to indicate that it has been received.
A NOTIFY requests contain an Event header field indicating the package and a Subscription-State header field
indicating the current state of the subscription. The Event header field will contain the package name used in the
subscription.
A NOTIFY is always sent at the start of a subscription and at the termination of a subscription.
Posted 20th March 2013 by Pramod Kumar
Labels: SIP

0
Add a comment
10th January 2013
Four variants of BICC IP bearer set-up procedures are defined:
- Fast Forward
- Delayed Forward
- Fast Backward
- Delayed Backward
Those procedures differ on the way the bearer control information are exchanged, and on whether an APM
(Connected) message shall be sent by the originating BICC node once the bearer is ready for use.
- Bearer control information exchanges :
- In Fast bearer setup (forward or backward) and in delayed forward bearer establishment procedures,
the IP bearer establishment is done in the forward direction, i.e. the IPBCP request is sent from the originating
towards the terminating MGWs ; the bearer establishment request is sent in the IAM message in fast (forward
or backward) procedures, while it is sent in subsequent APM message, after a first IAM/APM exchange, in
case of delayed forward bearer establishment.
- In reverse, in the Delayed backward bearer establishment procedure, the IP bearer establishment is
done in the direction reverse to the call establishment direction, i.e. the IPBCP request is sent from the
terminating towards the originating MGWs, through a backward APM message.
- APM (Connected) exchange :
Type of BICC calls
BICC Bearer establishment procedures:
- In Forward bearer setup procedures, the terminating BICC node decides by its own whether it requires
or not the originating BICC node to send an APM (Connected) message once the bearer is ready for use at
the originating side.
- In Delayed backward bearer setup procedure, APM(Connected) is never sent (BICC protocol).
- In Fast backward bearer setup procedure, an APM(Connected) message shall always be sent (BICC
protocol).
Posted 10th January 2013 by Pramod Kumar
Labels: Call Flows, Codec Management, VOIP (Voice over IP)

0
Add a comment
3rd December 2012
The interfaces and protocols supported towards the networks are mentioned below:
[http://4.bp.blogspot.com/-J59OmJgtxwM/ULxV9a5i0aI/AAAAAAAABPg/1DYT1mqCKWs/s1600/interfaces.JPG]
Network Interf aces and Protocols
Posted 3rd December 2012 by Pramod
Labels: Codec Management
Core Network Architecture - Interfaces

0
Add a comment
23rd October 2012
Codec Management has following goals:
1.) Optimize the voice quality.
2.) Optimize the bandwidth efficiency
3.) Optimize the transcoder resource in MGW.
4.) Optimize the delay
Voice quality is measured in terms of the level, attenuation, delay, echo, and so on and may be used as a basis for the
iQoS assessments for conventional VoIP. Voice Quality is measured in terms of R-value and below 50 are not
Codec Management
Codec Management Objectives
Voice Quality:
recommended.
Standards Intrinsic quality (R)
------------------------------------------------------
ITU G.711 (64kbps) 94.3
ITU G.728 (12.kbps) 74.3
ETSI GSM-FR (13kbps) 74.3
ETSI GSM-HR (5.6kbps) 71.3
ETSI GSM-EFR (12.2kbps) 89.3
-----------------------------------------------------
Transcoding can be harmful for voice quality of a call and should be avoided if possible. In 2G, BSC is in charge of
transcoding while MSC is the incharge of transcoding in 3G. We have intention to minimise the Transcoder
to enhance the voice quality.
[http://1.bp.blogspot.com/-MC4wZ4nx8ZI/UIY4bi3uelI/AAAAAAAAAKE/MrBbw85JEuY/s1600/codec1.JPG]
Legacy networks use a consistent 64 kbps per channel. Use G.711, packet networks easily surpass 64 kbps.
Therefore, compress codecs must be used on core. Compression ratio of 8:1can be achieved with compressed
codecs along with the following techniques : silence suppression, AAL2/RTP multiplexing, IP header compression.
The third goal of the codec management is to optimize the transcoder resources in the MGW. So, TrFO must
be used whenever possible.
Delay can be minimized if reduce the number of transcoders. We can reduce the transcoding time in call.
Posted 23rd October 2012 by Pramod Kumar
Bandwidth efficiency:
Transcoder Resources optimization:
Optimization of delay:

0
Add a comment
19th October 2012
In Early legacy telephone network, A call between the two mobiles involved with two transcoding function at both the
end which decrease the voice quality. The Transcoding Function done by the TRAU (Transcoding and Rate Adaptation
Unit) to compress and decompress the speech.
TFO (Tandem Free Operation) enables to avoid the traditional double speech encoding / decoding in MS to MS call
configurations. TFO uses in-band signalling and procedures for transcoders to enable compressed speech to be
maintained between a pair of transcoders.
So the main objective of TFO is the improvement of the voice quality for calls between 2 mobile subscribers, but no
resource optimisation is introduced as transcoder functions are always present in the path.
If TFO is activated between two end nodes, TFO Frames with compressed speech (e.g. AMR in LSB) as payload are
TFO - Tandem Free Operation
carried over 8 or 16 kbit/s channels mapped onto the least or two least significant bits of the 64 kbit/s PCM speech
samples. It is also carried the G.711 codec in MSB if it is not possible to achieve the TFO. So we can say that TFO is
used to achieve the voice quality if possible.
[http://2.bp.blogspot.com/-cdr2NJlVsYM/UIEVctA-oiI/AAAAAAAAAJw/A2Whhqdc0sU/s1600/tfo.jpg]
Tandem Free Operation is activated and controlled by the Transcoder Units after the completion of the call set-up
phase at both ends of an MS-MS, MS-UE, or UE-UE call configuration. The TFO protocol is fully handled and
terminated in the Transcoder Units. For this reason, the Transcoder Units cannot be bypassed in Tandem Free
Operation. This is the key difference with the feature called Transcoder Free Operation (TrFO).
Posted 19th October 2012 by Pramod Kumar

0
Add a comment
17th October 2012
In Early legacy telephone network, A call between the two mobiles involved with two transcoding function at both the
end which decrease the voice quality. The Transcoding Function done by the TRAU (Transcoding and Rate Adaptation
Unit) to compress and decompress the speech.
Transcoder Free Operation (TrFO) is transport of compressed speech, which eliminates unnecessary coding and
decoding of the signals when both end uses the same codecs. TrFO utilizes out of band signaling capabilities that
include the ability to determine the negotiated codec type to be used at the two end nodes. If the two end nodes are
capable of the same codec operations, it may be possible to traverse the entire packet network using only the
compressed speech (of the preferred codec). TrFO is basic function of codec Management.
Following are the benefits of achieving the TrFO:
1.) Improve the voice quality because of elimination of coding and decoding of suppressed codecs.
2.) We can optimize the resources by skipping the transcodes at both ends.
3.) We can increase the bandwidth in the Core Network.
4.) Increase the transmission delay by skipping the compression and decompression to G.711 codec.
It can improve the voice quality and above features using the TrFo and TFO simultaneously.
[http://4.bp.blogspot.com/-
gETJBRJA6do/UH5hAFlaI4I/AAAAAAAAAJc/moj04H3ZQuI/s1600/Trfo.jpg]
TrFO Operation
TrFO - Transcoder Free Operation

5
View comments
11th October 2012
HEX VALUE CAUSE
----------------------------------------------------------------
03 No route to destination
06 Channel unacceptable
08 Preemption
0E Query on Release QoR
10 Normal clearing
11 User busy
12 No user responding
13 No answer from user (user alerted)
14 Subscriber absent
15 Call rejected
16 Number changed
17 Redirection to new destination
18 Call rejected because of a feature at the destination
19 Exchange routing error
1A Non selected user clearing
1B Destination out of Order
1C Invalid number format (address incomplete)
1D Facility rejected
1E Response to Status Enquiry
1F Normal, unspecified
22 No circuit/channel available
26 Network out of order
29 Temporary failure
39 Bearer capability not authorized
51 Invalid call reference value
52 Identified channel does not exist
54 Call identity in use
57 User not member of Closed User Group
58 Incompatible destination
5F Invalid message, unspecified
60 Mandatory information element is missing
6F Protocol error, unspecified
7F Interworking, unspecified
Labels: SS7 Protocol Stack
ISUP Release Cause Values

0
Add a comment
11th October 2012
Service Name HEX BINARY
==================================================
CLIP 11 00010001
CLIR 12 00010010
COLP 13 00010011
COLR 14 00010100
All Call Forward 20 00100000
CFU 21 00100001
All Conditional call forward 28 00101000
CFB 29 00101001
CFNRY 2A 00101010
CFNRc 2B 00101011
CD 24 00100100
ECT 31 00110001
CW 41 01000001
CH 42 01000010
CCBs-A 43 01000011
CCBs-B 44 01000011
MPTY 51 01010001
AOCI (information) 71 01110001
AOCC (Charging) 72 01110010
All call Barring 90 10010000
Outgoing call Barring 91 10010001
Supplementary Service Codes
baoc 92 10010010
boic 93 10010011
boicExHC 94 10010100
Barring of Incoming calls 99 10011001
baic 9A 10011010
bicRoam 9B 10011011
Abbreviation:
CLIP : Calling Line Identification Presentation
CLIR: Calling Line Identification Restriction
COLP: Connected Line Identification Presentation
COLR: Connected Line Identification Restriction
CFU: Call Forwarding Unconditional
CFB: Call Forwarding Busy
CFNRy: Call Forwarding No Reply
CFNRc: Call Forwarding Not Reachable
ECT: Explicit Call Transfer
CW: Call Waiting
MPTY: Multi Party
CH: Call Hold
AOCI: Advice of Charge Indicator
BAOC: Barring of All Outgoing Calls
BOIC: Barring of outgoing International calls
BAIC: Barring of All Incoming Calls
BIC-ROAM: Barring of all incoming call while roaming.
Labels: GSM

0
Add a comment
9th October 2012
Here is UMTS subscriber call flow with the core network.
MS-A MSC MS-B
****************************************************************************************************
-------Initial_UE(CM_SERVICE_REQ) -->|
------------Dir_Trnx(AUTH_REQ) <--|
-------------Dir_Trnx(AUTH_RSP) -->|
---------------SecurityModeCmd <--|
--------------SecurityModeComp -->|
-----Dir_Trnx(TMSI_RELOC_CMD) <--|
----Dir_Trnx(TMSI_RELOC_COMP) -->|
-------------Dir_Trnx(SETUP) -->|
---------Dir_Trnx(CALL_PROC) <--|
----------------RabAssignReq <--|
----------------RabAssignRsp -->|
|--> PAGING ---------------------------
|<-- Initial_UE(PAGE_RSP) -------------
|--> Dir_Trnx(AUTH_REQ)--------------
|<-- Dir_Trnx(AUTH_RSP)---------------
|--> SecurityModeCmd -------------------
|<-- SecurityModeComp------------------
|--> Dir_Trnx(TMSI_RELOC_CMD)------
|<-- Dir_Trnx(TMSI_RELOC_COMP) ---
|--> Dir_Trnx(SETUP) -------------------
|<-- Dir_Trnx(CALL_CONF) --------------
|--> RabAssignReq ------------------------
|<-- RabAssignRsp -------------------------
|<-- Dir_Trnx(CALL_ALERT) -------------
-----------Dir_Trnx(CALL_ALERT) <--|
|<-- Dir_Trnx(CALL_CONNECT)----------
|--> Dir_Trnx(CALL_CONNECTACK)----
-------Dir_Trnx(CALL_CONNECT) <--|
---Dir_Trnx(CALL_CONNECTACK) -->|
<--------------------------------------Call Connected at this stage---------------------------->
|<-- Dir_Trnx(CALL_DISCONNECT) ------
|--> Dir_Trnx(CALL_REL) ------------------
|<-- Dir_Trnx(CALL_RELCOMP) -----------
|<-- Dir_Trnx(CALL_DISCONNECT)---
|-- Dir_Trnx(CALL_REL)-------------------->
3G Call Flow
|--> IuReleaseCmd ---------------------------
|<-- IuReleaseComp --------------------------
--------Dir_Trnx(CALL_RELCOMP) <--|
------------------IuReleaseCmd <--|
------------------IuReleaseComp -->|
*************************************************************************************************
Labels: Call Flows

0
Add a comment
6th October 2012
***********************************************************************
Mobile Station MSC
*************************************************************
----------------------Initial_UE(CM_SERVICE_REQ) -->|
---------------------------Dir_Trnx(AUTH_REQ) <--|
---------------------------Dir_Trnx(AUTH_RSP) -->|
-----------------------------Cipher Mode Command <--|
-----------------------------Cipher Mode Complete -->|
---------------------Dir_Trnx(TMSI_RELOC_CMD) <--|
----------------------Dir_Trnx(LOCUPD_ACCEPT) <--|
------------------------TMSI_RELOC_COMP <--|
--------------------------------Clear Cmd <--|
--------------------------------Clear Comp -->|
***********************************************************************
*******************************************************************
00 21 57 05 08 00 13 f0 79 00 01 00 01 17 12 05 08 70 13 f0 79 ff fe 30 08 89 88 88 12 45 12 00 00 21 01 00
00 Message discriminator
21 length
57 message type BSSMAP
05 08 00 13 f0 79 00 01 00 01 ID, length and value of Cell Identifier
Cell Identifier
05 IE
08 Length
00 Cell Identifier discriminator
13 F0 MCC1-> 3, MCC2 ->1, MCC3-> 0 MCC: 310
79 MNC1->9, MNC2->7 MNC: 97
00 01 LAC: 1.Represent LAC in hex and put in two bytes
00 01 CI: 1 represents CI in hex and put in two bytes
17 12 message type and length of layer3
05 TI flag, value and protocol discriminator (Mobility management).
08 message type of LU
70 Chiperkey sequence No.
13 f0 79 ff fe Location Area Identification
30 08 89 88 88 12 45 12 00 00 IMSI
21 01 00 Mobility Management.
********************************************
01 00 13 05 12 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 Message Discriminator
Location Update Message Decoding
Location Update Flow :
CM Service Request/Location Update Request
Authentication Request
00 Ctrl Channel not further specified (00), spare (000), sapi (000)
13 Length (19)
05 Mobility Management
12 Message Type DTAP
01/02 Possible value for ciphering key sequence number
00 00 00 00 00 00 00 00 00 Authentication RAND
00 00 00 00 00 00 00
**********************************************
01 00 06 05 54 00 00 00 00
06 Length (06)
54 Message Type
00 00 00 00 Authentication SRES
*************************************************
00 01 58
01 Length (1)
58 Message Type
***********************************
00 0b 54 12 03 30 59 81 13 02 60 14 00
0b Length (10)
54 Message Type
12 Classmark Information Type 2
03 Length (03)
30 59 81 Class Mark
13 Classmark Information Type 3
02 Length (02)
60 14 Class Mark
00 end of Optional parameters.
********************************************
00 0e 53 0a 09 07 00 00 00 00 00 00 00 00 23 01
0e Length (15)
53 Message Type
0a Encryption Information
09 Length (09)
07 00 00 00 00 00 00 00 00 Encryption Information
23 Cipher Response Mode (Phase 2)
01 Spare/ IMEISV must be Included By The Mobile Station
00 10 55 20 0b 17 09 33 05 70 87 70 35 17 01 f9 2c 01
10 Length (17)
55 Message Type
20 Layer 3 Message contents (Phase 2)
Authentication Response
Class Mark Request
Class Mark Update
Cipher Mode Command
Cipher Mode Complete
0b Length (11)
17 09 33 05 70 87 70 35 17 01 f9 Contents
2c Chosen Encryption Algorithm
01 No Encryption used
********************************************
01 00 0e 05 02 13 f0 69 00 03 17 05 f4 0f 2f 20 04 00 02 01
0e Length (15)
02 Message Type
13 F0 MCC1-> 3, MCC2 ->1, MCC3-> 0 MCC: 310
69 MNC1->9, MNC2->6 MNC: 96
00 03 LAC
17 Mobility Identity
05 Parameter Length
f4 ST 0/Even Number of Address Signals / TMSI
0f 2f 20 04 00 02 01 Identity Digits
******************************
00 04 20 04 01 09
04 Length (04)
20 Message Type
04 Cause
01 Length
09 Extension bit (last octet) / Call Control Normal Event
*****************************
00 01 21
01 Length (1)
21 Message Type
Labels: Call Flows
Location Update Accept
Clear Command
Clear Complete

2
View comments
27th September 2012
The Signalling Connection Control Part (SCCP) message are used by the peer to peer protocol. Following are the
SCCP message used by the peer to connection oriented and connection less services.
Application that uses the service of SCCP are called Subsystems. Refer the SCCP structure
[http://telecomprotocols.blogspot.com/2012/09/ss7-protocol-stack-sccp.html] for detail SCCP structure.
Classes of service:
Class 0Basic connectionless class - it has no sequencing control. i does not impose any condition on SLS,
therefore SCCP message can be delivered in out-of-sequece.
Class 1In-sequence delivery connectionless class - it adds the sequence control to class 0 service by requiring to
insert the same SLS to all NSDU.
Class 2Basic connection-oriented class - Assign the local reference numbers (SLR,DLR) to create logical
connection. it does not provide the flow control, loss, and mis-sequence detection.
SCCP Messages
L7w1xQzk7wQ/UGP2Fhb-vLI/AAAAAAAAAI4/rBUclMCwTRI/s1600/sccp.JPG]
Class 3Flow control connection-oriented class - Class 3 is an enhanced connection-oriented service that offers
detection of both message loss and mis-sequencing
1. Connection Request (CR): Connection Request message is initiated by a calling SCCP to a called SCCP to request the
setting up of a signalling connection between two entities. On Reception of CR message, the called SCCP initiates the setup
signalling connection. CR message have the Source Local Reference (SLR) as an address of originating entity. It is used during
connection establishment phase by connection-oriented protocol class 2 or 3.
2. Connection Confirm (CC): Connection Confirm message is initiated by the called SCCP to indicate to the calling
SCCP that it has performed the setup of the signaling connection. On reception of a Connection Confirm message, the
calling SCCP completes the setup of the signaling connection. CC message have the SLR as an address of called
entity and DLR as the address of originating entity. It is used during connection establishment phase by connection-
oriented protocol class 2 or 3.
3. Connection Refused (CREF): Connection Refused message is initiated by the called SCCP or an
intermediate node SCCP to indicate to the calling SCCP that the setup of the signalling connection has been
refused. It is used during connection establishment phase by connection-oriented protocol class 2 or 3.
4. Data Acknowledgement (AK): Data Acknowledgement message is used to control the window flow control mechanism,
which has been selected for the data transfer phase. It is used during the data transfer phase in protocol class 3.
5. Data Form 1 (DT1): A Data Form 1 message is sent by either end of a signalling connection to pass transparently
SCCP user data between two SCCP nodes. It is used during the data transfer phase in protocol class 2 only.
6. Data Form 2 (DT2): A Data Form 2 message is sent by either end of a signalling connection to pass transparently
SCCP user data between two SCCP nodes and to acknowledge messages flowing in the other direction. It is used
during the data transfer phase in protocol class 3 only.
7. Expedited Data (ED): An Expedited Data message functions as a Data Form 2 message but includes the ability to
bypass the flow control mechanism which has been selected for the data transfer phase. It may be sent by either end of
the signalling connection. It is used during the data transfer phase in protocol class 3 only.
8. Expedited Data Acknowledgement (EA): An Expedited Data Acknowledgement message is used to acknowledge
an Expedited Data message. Every ED message has to be acknowledged by an EA message before another ED
message may be sent. It is used during the data transfer phase in protocol class 3 only.
9. Inactivity Test (IT): An Inactivity Test message may be sent periodically by either end of a signalling connection
section to check if this signalling connection is active at both ends, and to audit the consistency of connection data at
both ends. It is used in protocol classes 2 and 3.
10. Protocol Data Unit Error (ERR): A Protocol Data Unit Error message is sent on detection of any protocol errors. It
is used during the data transfer phase in protocol classes 2 and 3.
11. Released (RLSD): A Released message is sent, in the forward or backward direction, to indicate that the sending
SCCP wants to release a signalling connection and the associated resources at the sending SCCP have been brought
into the disconnect pending condition. It also indicates that the receiving node should release the connection and any
other associated resources as well. It is used during connection release phase in protocol classes 2 and 3.
12. Release Complete (RLC): A Release Complete message is sent in response to the Released message indicating
that the Released message has been received, and the appropriate procedures have been completed. It is used
during connection release phase in protocol classes 2 and 3.
13. Reset Request (RSR): A Reset Request message is sent to indicate that the sending SCCP wants to initiate a
reset procedure (re-initialization of sequence numbers) with the receiving SCCP. It is used during the data transfer
phase in protocol class 3.
14. Reset Confirm (RSC): A Reset Confirm message is sent in response to a Reset Request message to indicate that
Reset Request has been received and the appropriate procedure has been completed.
It is used during the data transfer phase in protocol class 3.
15. Subsystem-Prohibited (SSP): A Subsystem-Prohibited message is sent to concerned destinations to inform
SCCP Management (SCMG) at those destinations of the failure of a subsystem. It is used for SCCP subsystem
management.
16. Subsystem-Allowed (SSA): A Subsystem-Allowed message is sent to concerned destinations to inform those
destinations that a subsystem which was formerly prohibited is now allowed or that a SCCP which was formerly
unavailable is now available. It is used for SCCP management.
17. Subsystem-Status-Test (SST): A Subsystem-Status-Test message is sent to verify the status of a
subsystem marked prohibited or the status of an SCCP marked unavailable. It is used for SCCP management.
18. UnitData (UDT): A Unitdata message can be used by an SCCP wanting to send data in a connectionless mode. It
is used in connectionless protocol classes 0 and 1.
19. Unitdata Service (UDTS): A Unitdata Service message is used to indicate to the originating SCCP that a UDT sent
cannot be delivered to its destination. Exceptionally and subject to protocol interworking considerations, a UDTS might
equally be used in response to an XUDT or LUDT message. A UDTS message is sent only when the option field in that
UDT is set to "return on error". It is used in connectionless protocol classes 0 and 1.
20. Extended Unitdata (XUDT): An Extended Unitdata message is used by the SCCP wanting to send data (along with
optional parameters) in a connectionless mode. It is used for the segmentation of large message into more XUDT
messages. It is used in connectionless protocol classes 0 and 1.
21. Extended Unitdata Service (XUDTS): An Extended Unitdata Service message is used to indicate to
the originating SCCP that an XUDT cannot be delivered to its destination. It is used in connectionless protocol
classes 0 and 1.
22. Subsystem Congested (SSC): A Subsystem Congested message is sent by an SCCP node when it experiences
congestion. It is used for SCCP subsystem management.
23. Long Unitdata (LUDT): Long Unitdata message is used by the SCCP to send data (along with optional
parameters) in a connectionless mode. When MTP capabilities according to Recommendation Q.2210 are present, it
allows sending of NSDU sizes up to 3952 octets without segmentation. It is used in Connectionless protocol classes 0
and 1.
24. Long Unitdata Service (LUDTS): A Long Unitdata Service message is used to indicate to the
originating SCCP that an LUDT cannot be delivered to its destination. It is used in connectionless protocol
classes 0 and 1.
25. Subsystem-Out-of-Service-Request (SOR): A Subsystem-Out-of-Service-Request message is used to allow
subsystems to go out-of-service without degrading performance of the network. When a subsystem wishes to go out-of-
service, the request is transferred by means of a Subsystem-Out-of-Service-Request message between the SCCP at
the subsystem's node and the SCCP at the duplicate subsystems, node.
It is used for SCCP subsystem management.
26. Subsystem-Out-of-Service-Grant (SOG): A Subsystem-Out-of-Service-Grant message is sent, in response to a
SubsystemOutofServiceRequest message, to the requesting SCCP if both the requested SCCP and the backup of
the affected subsystem agree to the request. It is used for SCCP subsystem management.
Posted 27th September 2012 by Pramod Kumar

0
Add a comment
11th September 2012
rS3es3A3NQI/UEmDWcT8ipI/AAAAAAAAAH8/y2eJXo7pHAI/s1600/3gpp.JPG]
Why LTE? The first question came into mind is why LTE? we are having 2G and 3G well established in market, then
what is the requirement of LTE or so called 4G.
But before proceeding let me clear LTE is not considered as 4G but the 3.9G due to some limitation.
To answer the question, the subscribers and business users are discovered the power of wireless broadband through
the advanced phones. Today internet are used for video streaming, live video, You Tube, Maps, Social Sites and web
search.
Because of so much to do on internet, consumers wants the high speed in data transfer on the go and the solution is
LTE. The standards of LTE developed by 3GPP.
LTE Provides following features and application for users and business:
LTE - Long Term Evolution
Improve QoS by decreasing the latency time.
provide the connectivity for non-traditional device like cars
provide the communication, entertainments, personal assistance.
Improving the services
Reducing the transport network cost.
All IP Network (AIPN).
2G/3G vs LTE:
- 2G and 3G supports voice traffic on CS (Circuit Switched) Network and Data service on packet netwok
- LTE provides voice and data over IP (packet network); single channel End to End and all-IP. however current release
of LTE (3GPP Release 8) does not support voice over LTE.
LTE Architecture:
[http://3.bp.blogspot.com/-VOOHx-XOGpc/UEbrF1tT2lI/AAAAAAAAAHU/gUrMhig9kJ0/s1600/lte_archi.JPG]
Entity Summery:
MME (Mobile Management Entity): MME provides mobility and session control management.
SGW (Serving Gateway): Routes and forwards the user data packets.
PGW (PDN Gateway): Provides UE session connectivity to external packet data network (PDN).
PCRF : Supports service data flow detection, policy enforcement, and flow based charging.
eNodeB: Receive and sends radio signals to and from the antennas. Schedules uplink and downlink data to/from
the UE. Provides Ethernet links to the EPC elements and other eNodeB.
LTE eUTRAN architecture elements:
MIMO (Multiple-Input and Multiple-Output): Input output refers to the channels. It requires multiple antennas at
transmitter and receivers. It increase throughput.
[http://4.bp.blogspot.com/-gbZy-Kqvn-Q/UEcaBFvzKcI/AAAAAAAAAHo/AR9UNRVc1uA/s1600/lte_mimo.JPG]
LTE Modulation Techniques:
OFDMA (Orthogonal Frequency Division Multiple access): OFDMA on the downlink, Minimal interference.
easily adapts to frequency and phase distortions. It provides higher throughput in same bandwidth by the
overlapping frequencies. It requires more power at transmission.
SC-FDMA (Single-Carrier Frequency Division Multiple Access): SC-FDMA on the uplink, low sensitivity to
carrier frequency offset. Chosen over OFDMA for uplink because OFDMA uses a lot of power. Lower throughput
than OFDMA because no overlap and it require less power. It is used UL to convey UE battery.
MME Functionality:
Communicates with the HSS for the user authentication and subscriber profile downloads.
Communicates with the eNodeB and SGW for the session control and bearer setup.
MME Interfaces:
S10: To other MMEs
S1-MME: MME to eNodeB
S6a: MME to HSS
S11: MME to HSS
S13: MME to EIR
X1_1 and X2: to IRI for Lawful interception
[http://3.bp.blogspot.com/-pymIzX984YY/UEmFVPeGUjI/AAAAAAAAAIM/9tLleQia-8U/s1600/lte_interfaces.JPG]
SGW Functionality:
Serves as local mobility anchor for the UE - terminates the packet data network interface towards the eUTRAN.
Support user-plan mobility - performs IP routing and forwarding functions and maintains data paths between the
eNodeBs and the PGW.
SGW Interfaces:
S5 from the PGW (User and Control traffic)
S8 from visiting SGW to Home PGW
S11 to the MME (For Control Traffic)
S1-U to the eNodeB (User Traffic)
PGW Functionality:
Provide the UE with the IP address.
Connect user to PDN.
Facilitates flow-based charging (Provides records to external billing systems)
Serves as the cross-technology mobility anchor (Support mobility between 3GPP/non-3GPP access to Non-
3GPP/3GPP access.
Per-User based packet filtering.
PGW interfaces:
S5 from the SGW ( for the user and control traffic)
S8 from the visiting SGW to Home PGW (Roaming, user and control traffic)
SGi to the packet data network (User traffic).
Gx to the PCRF (for the policy control)
PCRF Functionality:
Policy management entity that provides dynamic control of QoS and charging policies for the service data flows
(SDFs)
Decide how the SDFs will be treated by the PGW
On the UE attachments, the PCRF:
1. Receive the request for the policies for the default bearers.
2. Retrieve the user profiles from SPR and executes the rule-sets for the decision for the policy and charging.
3. Responds the PGW with the PCC rule.
PCRF Interfaces:
Gx to the PCRF (policy contol)
Sp to the SPR (For the subscriber repository).
Labels: 4G, LTE

0
Add a comment
10th September 2012
For call related message, there are two type of solutions defined for portability Domain:
A. Mobile Number Portability-Signaling Relay Function (MNP- SRF): it is based solution acts on
SCCP addressing and also makes use of NP database.
B. IN- Related Solution: IN based solution allows the MSCs to retrieve routing information from NPDB.
A. Mobile Number Portability-Signaling Relay Function (MNP- SRF) Scenarios:
dXBE3rrXxOI/UESRI3LAmtI/AAAAAAAAAD4/pz6-X_QeVVo/s1600/port_achitecture_MNP-SRF.JPG]
Figure- Call related case - Signalling Relay Function (SRF) solution
Call A.1: Call to a non-ported number:
[http://1.bp.blogspot.com/-ymwWPwa2w2I/UESJARDo5SI/AAAAAAAAADQ/pU7N7iI4zIY/s1600/non-ported.JPG]
MNP Call Flows
Fig 1: Call to a non-ported number
1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the subscription network being the
number range holder network, if the number is non-ported.
2. When GMSCa receives the ISUP IAM, , it requests routing information by submitting a MAP SRI to the
MNP_SRF/MATF.
3. When the MNP_SRF/MATF receives the message, the MNP_SRF/MATF analyses the MSISDN in the CdPA and
identifies the MSISDN as being non-ported. The MNP_SRF/MATF function then replaces the CdPA by an HLRB
address. After modifying the CdPA, the message is routed to HLRB.
4. When HLRB receives the SRI, it responds to the GMSCb by sending an SRI ack with an MSRN that identifies the
MSB in the VMSCb.
5. GMSCb uses the MSRN to route the call to VMSCb.
6. IAM requires special NOA
Call A.2 : Call to the Ported Number Originating Network = Subscription Network Direct Routing:
Kij9u85sfCs/UESK4avA2rI/AAAAAAAAADY/XE0Ivwcd-mE/s1600/ported-direct.JPG]
Fig 2: Call to the Ported Number Originating Network = Subscription Network
1. MSA originates a call to MSISDN.
2. VMSCa routes the call to the networks GMSCa.
3. When GMSCa receives the ISUP IAM, it requests routing information by submitting a MAP SRI to the
MNP_SRF/MATF.
4. When the MNP_SRF/MATF receives the message, it analyses the MSISDN in the CdPA and identifies the MSISDN
as being ported into the network. The MNP_SRF/MATF function then replaces the CdPA by an HLRA address.
After modifying the CdPA, the message is routed to HLRA.
5. When HLRA receives the SRI, it responds to the GMSCa by sending an SRI ack with an MSRN that identifies the
MSB in the VMSCb.
6. GMSCa uses the MSRN to route the call to VMSCb.
[http://3.bp.blogspot.com/-Ulcgcb-
Call A.3: Mobile Originated Call to a Ported or not known to be Ported Number Originating
Network=Subscription Network Direct Routing
y8Ps/UESOg7RSy6I/AAAAAAAAADo/mcYnuAk3Dps/s1600/ported-out.JPG]
Fig3: Mobile Originated Call to a Ported or not known to be Ported Number Direct Routing
1. MSA originates a call to MSISDN.
2. VMSCA routes the call to the networks GMSCA.
3. When GMSCA receives the ISUP IAM, it requests routing information by submitting a MAP SRI to the
MNP_SRF/MATF.
4. When the MNP_SRF/MATF receives the message, it analyses the MSISDN in the CdPA and identifies
the MSISDN as not known to be ported or being ported to another network. As the message is a SRI
message, the MNP_SRF/MATF responds to the GMSCa by sending an SRI ack with a RN + MSISDN;
For the case the number is not known to be ported the routing number may be omitted.
5. GMSCa uses the (RN +) MSISDN to route the call to GMSCb in the subscription network. Depending on
the interconnect agreement, the RN will be added in the IAM or not.
Call 4: Call to a Ported Number Indirect Routing
[http://3.bp.blogspot.com/-ayYVUEYKKm4/UESQAgN-
doI/AAAAAAAAADw/silf4RmuMIQ/s1600/ported-indirect.JPG]
Fig4: Call to a Ported Number Indirect Routing
1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the number range holder network.
2. When GMSCa in the number range holder network receives the ISUP IAM, it requests routing information by
submitting a MAP SRI to MNP_SRF/MATF.
3. When the MNP_SRF/MATF receives the message, it analyses the MSISDN in the CdPA and identifies the MSISDN
as being ported to another network. As the message is an SRI message, the MNP_SRF/MATF responds to the
GMSCa by sending an SRI ack with a RN + MSISDN
4. GMSCa uses the RN + MSISDN to route the call to GMSCb in the subscription network. Depending on the
interconnect agreement, the RN will be added in the IAM or not.
Call A.5: Call to a Ported Number Indirect Routeing with Reference to Subscription Network
[http://3.bp.blogspot.com/-FtDddkt5tlY/UESUN3vxI2I/AAAAAAAAAEI/k_FEH4LO-rM/s1600/portedout_indirectrouting.JPG]
Fig5: Call to a Ported Number Indirect Routeing with Reference to Subscription Network
1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the number range holder network.
2. When GMSCA in the number range holder network receives the ISUP IAM, it requests routeing information by
submitting a MAP SRI to the MNP_SRF/MATF. The TT on SCCP may be set to SRI.
3. When MNP_SRF/MATF receives the message, MNP_SRF/MATF operation is triggered. The MNP_SRF/MATF
functionality analyses the MSISDN in the CdPA and identifies the MSISDN as being ported to another network. As
the message is a SRI message, the MNP_SRF/MATF function relays the message to the subscription network by
adding a routeing number to the CdPA which information may be retrieved from a database. After modifying the
CdPA, the message is routed to the subscription network.
4. When MNP_SRF/MATF in the subscription network receives the SRI, it responds to the GMSCA in the number
range holder network by sending a SRI ack with a RN + MSISDN.
5. GMSCA uses the (RN +) MSISDN to route the call to GMSCB in the subscription network; Depending on the
interconnect agreement, the RN will be added in the IAM or not.
6. When GMSCB in the subscription network receives the ISUP IAM, it requests routeing information by submitting a
MAP SRI to MNP_SRF/MATF. The TT on SCCP may be set to SRI.
7. When MNP_SRF/MATF receives the message, MNP_SRF/MATF operation is triggered. The MNP_SRF/MATF
functionality analyses the MSISDN in the CdPA and identifies the MSISDN as being ported into the network. The
MNP_SRF/MATF function then replaces the CdPA by an HLRB address which information may be retrieved from a
database. After modifying the CdPA, the message is routed to HLRB.
8. When HLRB receives the SRI, it responds to the GMSCB by sending an SRI ack with an MSRN that identifies the
MSB in the VMSCB.
9. GMSCB uses the MSRN to route the call to VMSCB.
B. IN- Related Solution:
The following network operator options are defined for the MT calls in the GMSC:
- Terminating call Query on Digit Analysis (TQoD)
- Query on HLR Release (QoHR).
The following network operator option is defined for MO calls in VMSCA and for forwarded calls in the GMSC and
VMSCB:
- Originating call Query on Digit Analysis (OQoD).
Call B.1 Call to a non-ported number, no NP query required:
[http://4.bp.blogspot.com/-ho398TcUftU/UESWqM3-VVI/AAAAAAAAAEY/NaeROM5v7tA/s1600/non-ported_b.1.JPG]
Fig 6: Call to non-ported Number, no query required
1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the Number range holder network
being the Subscription network.
2. When GMSCB receives the ISUP IAM, it requests routeing information by submitting a MAP SRI to the HLRB
including the MSISDN in the request.
3. The HLRB requests an MSRN from the MSC/VLRB where the mobile subscriber currently is registered.
4. The MSC/VLRB returns an MSRN back to the HLRB.
5. The HLRB responds to the GMSCB by sending an SRI ack with an MSRN.
Call B.2: TQoD Number is not ported
[http://4.bp.blogspot.com/-bh3pnZ6qySI/UESlPOKup8I/AAAAAAAAAEo/7EtdE5THQ8M/s1600/Tqod-Notported.JPG]
Fig 7: TQoD Number is not ported
1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the Number range holder network
being the Subscription network.
2. When GMSCB receives the ISUP IAM, it will send a database query to the NPDB as a result of analysis of the
received MSISDN. The MSISDN is included in the query to the NPDB.
3. The NPDB detects that the MSISDN is not ported and responds back to the GMSCB to continue the normal call
setup procedure for MT calls.
4. The GMSCB requests routeing information by submitting a MAP SRI to the HLRB, including the MSISDN in the
request.
5. The HLRB requests an MSRN from the MSC/VLRB where the mobile subscriber owning the MSISDN currently is
registered.
Call B.3: TQoD Number is ported
[http://2.bp.blogspot.com/-grscysZP02M/UESl5CPCI-I/AAAAAAAAAEw/-JRbA8ane88/s1600/Tqod-ported.JPG]
Fig 8: TQoD Number is ported
1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the Number range holder network.
2. When GMSCA receives the ISUP IAM, it will send a database query, including the MSISDN, to the NPDB as a result
of analysis of the received MSISDN.
3. The NPDB detects that the MSISDN is ported and responds back to the GMSCA with a Routeing Number pointing
out the Subscription network.
4. The call is routed to the Subscription network based on the Routeing Number carried in ISUP IAM message; also
the MSISDN is included in IAM.
request. The capability to route messages to the correct HLR is required.
Call B.4: QoHR Number is ported
[http://2.bp.blogspot.com/-plVAprSq4LE/UESm2iHYwVI/AAAAAAAAAE4/GFYIDDj14kc/s1600/HLR-ported.JPG]
Fig 9: QoHR Number is ported
1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the Number range holder network.
2. When GMSCA receives the ISUP IAM, it requests routeing information by submitting a MAP SRI to the HLRA
including the MSISDN in the request.
3. The HLRA returns a MAP SRI ack with an Unknown Subscriber error since no record was found for the subscriber
in the HLRA.
4. When GMSCA receives the error indication form the HLRA, this will trigger the sending of a database query to the
NPDB, including the MSISDN in the query.
5. The NPDB detects that the MSISDN is ported and responds back to the GMSCA with a Routeing Number pointing
Call B.5: OQoD Number is not ported
[http://3.bp.blogspot.com/-bP5zgf-YFE8/UESnttyMlrI/AAAAAAAAAFA/9Ot94QcRh2c/s1600/Oqod-notported.JPG]
Fig 10: OQoD Number is not ported
1. A call is initiated by Mobile Subscriber A towards Mobile Subscriber B, using the MSISDN of the called subscriber.
2. When VMSCA receives the call setup indication, it will send a database query to the NPDB as a result of analysis
of the received MSISDN, including the MSISDN in the query.
3. The NPDB detects that the MSISDN is not ported and responds back to the VMSCA to continue the normal call
setup procedure for MO calls. Depending on database configuration option, the NPDB could either return a
Routeing Number on not ported calls, as done for ported calls, or the call is further routed using the MSISDN
number only towards the Number range holder network.
4. The call is routed to the Number range holder/Subscription network based on the MSISDN or Routeing Number
carried in ISUP IAM message.
request.
Call B.6: OQoD- Number is ported
[http://3.bp.blogspot.com/-GzIWOpIYcxY/UESoqbnEO8I/AAAAAAAAAFI/Jg14ftyLyDY/s1600/Oqod-ported.JPG]
Fig 11: OQoD- Number is ported
1. A call is initiated by Mobile Subscriber A towards Mobile Subscriber B, using the MSISDN of the called subscriber.
2. When VMSCA receives the call setup indication, it will send a database query to the NPDB as a result of analysis
of the received MSISDN including the MSISDN in the query.
3. The NPDB detects that the MSISDN is ported and responds back to the VMSCA with a Routeing Number pointing
Labels: MNP, Mobile Number Portability

0
Add a comment
9th September 2012
H.248/MEGACO Protocol
H.248 is protocol used between the MGC and MG in Master-Slave fashion. MEGACO is similar to MGCP. MGC uses
this protocol to control the MG.
MEGACO provide the following enhancement over the MGCP.
- Support multimedia and multi point conference enhanced service.
- Improve syntax for more efficient semantic message processing.
- TCP and UDP transport support
- Support either binary or text encoding.
Message Structure:
Message {
Transaction {
Action {
Command {
Descriptor {
Package {
Property { }}}}}}
MTACDPP
Message: Multiple Transactions can be concatenated into a message, which contains header, the version, and one or
more Transactions.
Syntax: MEGECA /version [senderIPAddress]:portNumer
Where: version = 1 to 99
Sender IP address = 32-bit IP address
Port Number = 16 bit value
The message header contains the identity of the sender. The message identity is set to a provisioned name of the
entity transmitting the message. The version number is two digit numbers, beginning with the version 1 for the present
version of the protocol.
Transaction: Command between the MGC and MG are grouped into the transaction.
Each of which identified by Transaction ID. Transaction ID assigned by the sender. Transaction reply is invoked by
receiver. There is one reply invocation per transaction.
Transaction ( transactionID { context ID {{{{}}}})
where Transaction ID = 1 to 4294967295 (a 32bit value)
Context ID= null to 65535 ( 16bit value)
Reply ( TID {CID})
The TID parameter must be the same as the corresponding transaction request. The CID must be specifying a value to
pertain to all responses for the actions.
Transaction Pending is invoked by the receiver indicates that the transaction is actively being processed, but has not
been completed. It is used to prevent the sender from assuming that the Transaction Request was lost if the
transaction takes some time to complete. The syntax for command is :
Pending ( TID {})
The TID must be same as the corresponding Transaction request.
The Root property normalMGExecutionTime is used to specify the interval within which the MGC expects a response
to any transaction from the MG. Another Root property normalMGCExecutionTime is used to indicate the interval within
which the MG should expect a response to any transaction from the MGC. Both of these properties are configurable by
the MGC and have the following value ranges
NormalMGExecutionTime = 100 to 5000 milliseconds
NormalMGCExecutionTime = 100 to 5000 milliseconds
Action: Action is a group of command to be executed in the same context. it does not have an own identifier.
Context is identified by a Context_ID, which is assigned by the MG when the first termination is Added to a context. The
context is deleted when the last termination is subtracted from a termination.
Command: Command are used to manipulate the logical entity of the protocol connection model, context and
termination. Commands provide the complete control of properties of the context and the terminations.
Commands are:
- ADD: The Add command adds a Termination to a Context. The first Termination add to a context creates a new
Context.
Request: Add = Termination_ID { [MediaDescriptor] [,EventDescriptor] [,SignalsDescritor] [,AuditDescriptor]}
Reply: Add = Termination_ID { [MediaDescriptor] [,EventDescriptor] [,SignalsDescritor][,ObservedEventsDescriptor]
[,StatisticsDescriptor] [,PackagesDescriptor] [,ErrorDescriptor] [,AuditDescriptor]}
- MODIFY: The Modify command modifies the properties, events and signals of a Termination.
Request: Modify = Termination_ID { [ MediaDescriptor] [,EventDescriptor] [,SignalsDescritor] [,AuditDescriptor]}
Reply: Modify = Termination_ID { [MediaDescriptor] [,EventDescriptor] [,SignalsDescritor]
[,ObservedEventsDescriptor] [,StatisticsDescriptor] [,PackagesDescriptor] [,ErrorDescriptor] [,AuditDescriptor]}
- SUBTRACT: The Subtract command disconnects a Termination from its Context and returns statistics on the
Termination's participation in the Context. The Subtract command on the last Termination in a Context deletes the
Context.
Request: Subtract = Termination_ID { [AuditDescriptor]}
Reply: Subtract = Termination_ID { [ MediaDescriptor] [,EventDescriptor] [,SignalsDescritor]
[,ObservedEventsDes[,StatisticsDescriptor[,PackagesDescriptor[,ErrorDescriptor] [,AuditDescriptor]}
- MOVE: The Move command atomically moves a Termination to another Context.
Request: Move = Termination_ID { [ MediaDescriptor] [,EventDescriptor] [,SignalsDescritor] [,AuditDescriptor]}
Reply: Move = Termination_ID { [ MediaDescriptor] [,EventDescriptor] [,SignalsDescritor]
[,ObservedEventsDescriptor] [,StatisticsDescriptor] [,PackagesDescriptor] [,ErrorDescriptor] [,AuditDescriptor]}
- Audit-value: The AuditValue command returns the current state of properties, events,
signals and statistics of Terminations.
Request: AuditValue = Termination_ID { AuditDescriptor}
Reply: AuditValue = Termination_ID { [MediaDescriptor] [,EventDescriptor] [,SignalsDescritor]
[,ObservedEventsDescriptor] [,StatisticsDescriptor] [,PackagesDescriptor]}
- Audit-Capability: Audit Capability commands returns the all possible proprties, events, signals and statistics of the
Termination.
- Notify: The Notify command allows the MG to inform the MGC of the occurrence of events in the MG.
Request: Notify = Termination_ID { [,ObservedEventsDescriptor] [,ErrorDescriptor]}
Reply: Notify = Termination_ID { [ErrorDescriptor]}
- Service Change: The ServiceChange command allows the MG to notify the MGC that a Termination or group of
Terminations is about to be taken out of service or has just been returned to service. ServiceChange is also used by
the MG to announce its availability to a MGC (registration), and to notify the MGC of impending or completed restart of
the MG. The MGC may announce a handover to the MG by sending it a ServiceChange command. The MGC may also
use ServiceChange to instruct the MG to take a Termination or group of Terminations in or out of service.
Request: ServiceChange = Termination_ID { ServiceChangeDescriptor}
Reply: ServiceChange = Termination_ID { (ServiceChangeDescriptor/ ErrorDescriptor)}
Terminations: A Termination is a logical entity on a MG that sources and/or sinks media and/or control streams. A
Termination is described by a number of characterizing Properties, which are grouped in a set of Descriptors that are
included in commands. Terminations have unique identities (TerminationIDs), assigned by the MG at the time of their
creation.
There are two type of terminations:
Ephemeral Terminations are created by means of an Add command. They are destroyed by means of a Subtract
command. These exist only for the duration of their use. These are created and destroyed.
Physical Termination: The physical terminations have the semi-permanent existence on the MGW. For example the
TDM channels that are exist as long as its provisioned on the MGW.
Context: Context is an association between collections of termination. There is special type of context called null
context, which contains the terminations that are not associated with any other termination.
Descriptors: Properties of the termination are organized syntactically into the descriptors. Parameters to the
commands are called Descriptors. Many commands share same descriptors.
- Modem Descriptors: Specifies the modem type and parameters.
- Multiplex Descriptors: Associates with the media and bearer in multimedia calls.
- Media Descriptors: Specifies the parameters of all media streams.These parameters are structured into two
descriptors: a TerminationState descriptor, which specifies the properties of a termination that are not stream
dependent and one or more Stream descriptors each of which describes a single media stream.
- Event Descriptors: Specifies the list of events that MG is requested to detect and report.
- EventBuffer Descriptors: Specifies the list of events and their parameters that MG is requested to detect and buffer
when EventBufferControl equals to lockStep.
- Signal Descriptors: Specifies the set of signals that media gateway is asked to apply to terminations.
- Audit Descriptors: Specifies the information is to be audited.
- Service Change Descriptors: Specifies the parameters between the MGC and MG when MG power up, termination
state change, MG or MGC failure happens, or MGC handoff.
- Digit Map Descriptors: A DigitMap is a dialing plan resident in the MG used for detecting and reporting digit events
received on a termination.
- Statistics Descriptors: The Statistics descriptor provides information describing the status and usage of a termination
during its existence within a specific Context.
- Package Descriptors: returns the list of package realized by the termination and it is used with the AuditValue
command.
- ObservedEvent Descriptors: notify event to MGC when detected used with the Notify Command.
- Topology Descriptors: A Topology descriptor is used to specify flow directions between terminations in a context. The
topology descriptor applies to a context instead of a termination.
- Error Descriptors: Specifies the Error code.
Package:
All properties, Events, Signals, and statistics used in the H.248 protocols are defined in packages. it is uniquely
identified by the packageID. Following are the Package defined:
- Generic (g): Signal Completion Event
- Base Root (root): Defines the generic properties of MG i.e. max number of contexts, system times value and
terminations
- Tone Generator (tg): define signal to generates the Tones.
- Tone Detection (tonedet): Defines events for audio tone detection. Needed for detection the DTMF tones.
- Basic DTMF Generators (dg): Defines signals for DTMF generation
- DTMF Detection (dd): Defines events for DTMF detection.
- Call Progress tones generators (cg): defines signals for call progress tones generation.
- Basic Continuity (ct): Defines events & signals for continuity tests.
- Network (nt): : Defines termination properties independent of the network type .
- Real Time Transport protocol (rtp): RTP transfer of the multimedia stream.
- TDM Circuits (tdmc): use for termination to support gain and echo control.
- Generic Announcements: Allows to support announcement functionality at a MG. Announcement will be played
endlessly by the MG, until the MGC stops the announcement.
- Media gateway resource congestion handling (chp): Allows the MG to control its load.
- 3GUP (threegup): Configures the User Plane functions in the MG
- TFO (threegtfoc): Defines events and properties for Tandem Free Operation
- Bearer characteristics (bcp) : Identify which bearer services are to be supported by a MG
Posted 9th September 2012 by Pramod
Labels: H.248, MEGACO, VOIP (Voice over IP)

0
Add a comment
8th September 2012
Mobile Number Portability (MNP):
Mobile Number Portability (MNP) is the ability for a UMTS or GSM mobile subscriber to change the subscription network
within a portability domain while retaining her original MSISDN.
Mobile Number Portability (MNP)
veVG8GphPhQ/UER4tAYyW1I/AAAAAAAAACw/Fu9cOkFxiVo/s1600/port1.JPG]
Fi g 1: General Archi tecture of Portabi l i ty for Cal l s
Few Definitions to understand the MNP feature:
Number Range Holder Network (NRHN): The Network to which number range containing the ported number has
been allocated.
For Example if a number which is in process of porting is belongs to Vodafone network, then the Vodafone treated as
Number Range Holder Network (NRHN).
Donor Network: A subscription network from which a number is ported-out in porting process. This may or may not be
the Number range holder network.
For example if a subscriber is ported-out from Vodafone to Airtel, then Vodafone network if called as Donor network. If
this number range belongs to Vodafone then it also called NRHN so in this NRHN and Donor network would be same
i.e. Vodafone. but if this number is already ported in to Vodafone from Idea and again it is ported out to Airtel, then the
Vodafone network is called as only Donor network and Idea would be NRHN.
Number Portability Database (NPDB): A Database which provides portability information like Number is ported out or
not (portability Status) and if ported out then provides the Routeing number (RN).
Routeing Number (RN): A Routeing number route the call to recipient network or subscription network. This is
provided by NPDB or MNP-SRF.
Number Portability Status: Information indicating the status of portability for Mobile subscriber. Portability can be:
- Own Number Ported Out
- Own Number not ported out
- Foreign number ported in
- Foreign number ported out to foreign network.
- Foreign number not know to ported
Originating Network: Network where the calling party located.
Subscription Network or Recipient Network: An recipient network for the Mobile subscriber in porting process.
For Example if a number which is in process of porting is belongs to Vodafone network and ported out to Airtel, then
Airtel
would be Recipient Network in this case.
Following routing methods are mentioned: these are the method implemented in portability domain based on
the operator agreements.
- Direct Routing: Direct Routing of calls is PLMN options that allows to route calls directly from the PLMNs supporting
this option to the ported subscriber's subscription network.
For example: In the Fig 1, if a message(7) is originated inside the portability domain, in a PLMN supports the direct
routing, this IAM (7) directly routed to the subscription network.
- Indirect Routing: Indirect Routeing of calls is a PLMN option which allows to route calls from the PLMN supporting
this option via the number range holder network to the ported subscribers subscription network.
For example In Fig 1, If a message(2) originated inside the portability domain, in a PLMN support indirect routing routes
this IAM(2) to Number Range holder network. The Number range holder network route the calls to subscription network.
- If a call originated outside the Portability domain, then the IAM(1) routes to NRHN and then NRHN routes message(1)
to Subscription network.
What changes needed to perform the portability:
case 1: if the number range holder network is identical with the donor network (Example if number is of Airtel and
ported to Vodafone):
Airtel(NRHN, Donor N/W) Vodafone (Recipient N/w) Idea ( Other N/w, Direct Routing)
================================================================================
HLR REMOVE ADD
NPDB rn=ADD to voda ADD ADD for vodafone
case 2: if the number range holder network is identical with the recipient network:(Example if number is of Airtel and
ported in to airtel from vodafone) Normal call.
Airtel(NRHN, receipint) Vodafone (DONOR N/w) Idea ( Other N/w, Direct Routing)
================================================================================
HLR ADD REMOVE
NPDB rn=remove remove remove
Case 3: if the number range holder network is different from both the recipient and the donor network: (Example if
number is of Airtel and ported in to idea from vodafone)
Airtel (NRHN) Vodafone(Donor N/W) Idea (Recipient N/w) BSNL( Direct Routing)
=================================================================================
HLR delete add
NPDB rn=update delete add update
Labels: MNP, Mobile Number Portability

0
Add a comment
7th September 2012
SIP stack handled over the following layer and data transfer based on following Internet Media Protocol stack:
Application Layer: H.232, SIP, RTP, DNS, DHCP
Transport Layer: TCP, UDP
Internet Layer: IP
Physical Layer: ATM, V90, Ethernet, Wireless 802.11
1. Physical Layer: it can be following:
- Ethernet LAN,
- DSL,
- ATM
- Wireless 802.11 network.
2. Internet Layer: used to route the packet across the network using the destination IP address. IP offers
following functionality and drawbacks with simplicity:
-- Connection less
-- Best-effort packet delivery protocol.
-- IP packets can be lost
-- IP packets can be delayed
-- IP packets cab be received out of sequence.
-- IP packet are not Acknowledged.
IP Address used over the public internet are assigned in blocks by the IANA (Internet Assigned Number Association
and IP address are globally unique.
3. Transport Layer: TCP/UDP/SCTP
3.1 TCP: TCP provides following functionality:
- TCP provides the reliable
- Connection oriented transport over IP.
- TCP uses the sequence numbers
- TCP uses ACK for reliability of transfer of message.
- Lost segments retransmitted until they are successfully received
- TCP works on well know port number.
The TCP cleint sends SYN (synchronization) message to open the connection, which (SYN) contains initial sequence
number, the client will use during the connection. The server respond with SYN message containing own initial
sequence number, and an acknowledgement number, indicating that it received the SYN from client. The client
completes the three-way handshake with an ACK or a DATA packet with the AK flag set to the server acknowledging
the server's sequence number. Now that the connection is open, either client or server can send data in DATA packets
called segments.
After sending the the segment, sender starts the timer,and if it expires, sender resend the segment.FIN message use to
close the TCP connection. Window size is use representing the initial maximum number of unacknowledged segments
is sent.
TCP-Client TCP-Server
------------------------SYN(SN_client)----------------------->
<--------------SYN/AK(SN_server, SN_client)----------------
Session Initiation Protocol (SIP)
Session Initiation Protocol (SIP)
----------------------------ACK------------------------------->
--------------------------------DATA-------------------------->
....................
<--------------------------------FIN----------------------------
---------------------------------ACK--------------------------->
3.2 UDP:
- UDP provides the unreliable transport across the Internet. No Ack of sent datagram.
- It does not have complexity like TCP.
- Best effort delivery service.

3.3 TLS:
TLS is based on SSL (secure sockets layer) and uses TCP for transport. it is used in https URI schemes.
TLS protocol have two layers:
3.3.1 TLS Trasport protocol:
- Used to provide the reliable and private transport,
- It is encrypted so that third party can not intercept the data.
3.3.2 TLS Handshake protocol:
- Used to establish the connection
- Negotiate the encryption keys used by TLS transport protocol and provide the authentication.
3.4 SCTP: SCTP is steam-based protocol. it is similar like TCP but have some advantage over the TCP.
Advantage of SCTP:
- Segmentation
- multi hoaming
- multi streaming
- unicast protocol
The SIP is an application layer protocol develop by IETF to setup, modify, and tear down multimedia session such as
Internet telephony calls over IP.
DNS ( Domain Name Service):
- DNS is used in the internet to map a symbolic name (like thomas.com) to an IP address (like 100.100.100.1).
- Domain is used to give the internet a human friendly feel.
- Domain names are organised in hierarchy. Each level of name is separated by the dot, with the highest level domain
on the right hand side.
Address Record (A Record):
- CNAME (Canonical Name)
- MX (Mail Exchange)
- TXT (Free Form text record)
- SRV (Service Record)
- NAPTR (Naming Authority Pointer)
SIP Request Message:
- INVITE
- ACK
- BYE
- REGISTER
- OPTIONS
- CANCEL
SIP Responses: Response code are generated with Numerical Numbers
- 1xx (Informational Class) like 100 Trying, 180 Ringing, 183 Session Progress.
- 2xx (Final Response Class) like 200 ok.
- 3xx (Forwarding Class)
- 4xx
- 5xx
SIP Call Flow:
UACa UACb
INVITE -------------------------------------->
100 Trying ------------------------------------->
<----------------------------------- 180 Ringing
<----------------------------------- 200 OK
ACK ------------------------------------>
<-------------Media Session Established--------------->
<------------------------------------ BYE
-------------------------------------> 200 OK
INVITE sip:marconi@test.org SIP/2.0
Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b
Max-Forwards: 70
To: G. Marconi <sip:Marconi@radio.org>
From: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341
Call-ID: <a href="mailto:123456789@lab.high-voltage.org">123456789@lab.high-voltage.org</a>
CSeq: 1 INVITE
Subject: About That Power Outage...
Contact: <sip:n.tesla@lab.high-voltage.org>
Content-Length: 158
v=0
o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org
s=Phone Call
c=IN IP4 100.101.102.103
t= 0 0
m= audio 1201 RTP/AVP 0 98
a=rtpmap:0 PCMU/8000
a=rtpmap:98 AMR/8000
a=fmtp:98 mode-set=0,2,4,7
SIP is text-encoded protocol. Description of header information:
- Via contains the address at which sender is expecting to receive responses to this request. usually written as a host
name that can be resolved into an IP address using a DNS query. It also contains a branch parameter that identifies
this transaction.
- Max-Forwards header field, which is initialized to some large integer and decremented by each SIP server, which
receives and forwards the request, providing simple loop detection.
- From header fields, which show the originator of the SIP request.
- TO header fields, which show the destination of the SIP request.
- Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the
softphone's host name or IP address.
The combination of the local tag (contained in the From header field), remote tag (contained in the To header field),
and the Call-ID uniquely identifies the established session, known as a dialog.
- CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each
new request within a dialog and is a traditional sequence number.
The Via header fields plus the Max-Forwards, To, From, Call-ID, and CSeq header fields represent the minimum
required header field set in any SIP request message.
- Contact contains a SIP or SIPS URI that represents a direct route to contact to sender. It is mandatory in invite
request.
- Content-Type contains a description of the message body(SDP).
- Content-Length contains an octet (byte) count of the message body.
The 180 Ringing response has the following structure:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b;received=100.101.102.103
To: G. Marconi <sip:marconi@radio.org>t;;tag=a53e42
Call-ID:123456789@lab.high-voltage.org
CSeq: 1 INVITE
Contact: <sip:marconi@tower.radio.org>
Content-Length: 0
Via header field contains original branch parameter and additional received parameter, this parameter contains the
literal IP address that the request was received from (IP address of requester from DNS).
To and From header field are not reversed but same as INVITE, which show SIP indicates the direction of request, not
the direction of message. To header now contains the tag. Response also contains the contact which have direct
address of recipient.
SIP/2.0 200 OK
Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b;received=100.101.102.103
To: G. Marconi <sip:marconi@radio.org>;tag=a53e42
Call-ID:123456789@lab.high-voltage.org
CSeq: 1 INVITE
Contact: <sip:marconi@tower.radio.org>
Content-Length: 155
v=0
o=Marconi 2890844528 2890844528 IN IP4 tower.radio.org
s=Phone Call
c=IN IP4 200.201.202.203
t=0 0
m=audio 60000 RTP/AVP 0
a=rtpmap:0 PCMU/8000
ACK sip:marconi@tower.radio.org SIP/2.0
Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bK321g
Max-Forwards: 70
To: G. Marconi <sip:marconi@radio.org>;tag=a53e42
Call-ID: <123456789@lab.high-voltage.org
CSeq: 1 ACK
Content-Length: 0
ACK have the same Cseq number but method is set to ACK. Branch parameter in the Via header field contains a new
transaction identifiers than the invite, since an ACK sent to acknowledge a 200 OK is considered
a separate transaction.This message exchange shows the SIP as an end-to-end signaling protocol.
a BYE request is sent by Marconi to terminate the media session:
BYE sip:n.tesla@lab.high-voltage.org SIP/2.0
Via: SIP/2.0/UDP tower.radio.org:5060;branch=z9hG4bK392kf
Max-Forwards: 70
To: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341
From: G. Marconi <sip:marconi@radio.org>;tag=a53e42
Call-ID: 123456789@lab.high-voltage.org
CSeq: 1 BYE
Content-Length: 0
The Via header field in this example is populated with Marconis host address and contains a new transaction identifier
since the BYE is considered a separate transaction from the INVITE or ACK transactions shown previously. The To and
From header fields reflect that this request is originated by Marconi, as they are reversed from the messages in the
previous transaction. Tesla, however, is able to identify the dialog using the presence of the same local and remote
tags and Call-ID as the INVITE, and tear down the correct media session.
SIP/2.0 200 OK
Via: SIP/2.0/UDP tower.radio.org:5060;branch=z9hG4bK392kf;received=200.201.202.203
To: Nikola Tesla <sip:n.tesla@high-voltage.org>;tag=76341
From: G. Marconi <sip:marconi@radio.org>;tag=a53e42
Call-ID: <a href="mailto:123456789@lab.high-voltage.org">123456789@lab.high-voltage.org</a>
CSeq: 1 BYE
Content-Length: 0
User Agent Client (UAC) initiates the request and User Agent Server (UAS) generates the responses. During the call, a
user agent will usally operate as both UAC and a UAS. A UA must understand any extensions listed in a Require
header field in a request.
A UA should advertise its capabilities and features in any request it sends. This allows other UAs to learn of them
without having to make an explicit capabilities query.
For example, the methods that a UA supports should be listed in an Allow header field. SIP extensions should be listed
in a Supported header field.
Message body types that are supported should be listed in an Accept header field.
SIP has two broad categories of URIs:
- Address of Record (AoR): corresponds to the user, it requires the database look-up and can be sent to more than
one device. Usually it is populated in To, From.
- Contact: it is device URI, and typically not required the database lookup.
SIP call with the Proxy:
Marconi Proxy Server Tesla
==================================================
-------INVITE------------->
------------INVITE--------------->
<---------------180 RINGING----
<------180 Ringing----------
<--------------200 OK-----------
<------200 OK-------------
----------------------------------ACK-------------------------->
<=================Media Session Established=========>
<----------------------------BYE---------------------------------
-----------------------------200 OK------------------------------>
Proxy is not really in the call. It facilitates the two end points locating and contacting each other. Proxy can be used in
further required message using the Record-Route header field.
Media is always end-to-end and not through the proxy.
REQUEST:
INVITE, REGISTER, BYE, ACK, CANCEL and OPTIONS original six methods in SIP 3261.
The REFER, SUBSCRIBE, NOTIFY, MESSAGE, UPDATE, INFO, and PRACK methods are described in separate RFCs.
- INVITE: used to establish the media session b/w UAs. INVITE is always acknowledge by ACK method. If the media
information contained in the ACK is not acceptable, then the called party must send a BYE
to cancel the sessiona CANCEL cannot be sent because the session is already established. A media session is
considered established when the INVITE, 200 OK, and ACK messages have been exchanged between the UAC and the
UAS. A successful INVITE.
An INVITE sent for an existing dialog references the same Call-ID as the original INVITE and contains the same To and
From tags. called a re-INVITE, the request is used to change the session characteristics or refresh the state of the
dialog. The CSeq command sequence number is incremented so that a UAS can distinguish the re-INVITE from a
retransmission of the original INVITE. UPDATE is sent to refersh the diagloue if media session did not established.
- BYE: The BYE method is used to terminate an established media session. Cancel is used to terminate the call which
did not establish the media session. BYE can only initiated by user agents. Proxies can initiates it.
- ACK: The ACK method is used to acknowledge final responses to INVITE requests.An ACK may contain an
application/sdp message body. This is permitted if the initial INVITE did not contain a SDP message body. If the INVITE
contained a message body, the ACK may not contain a message body. The ACK may not be used to modify a media
description that has already been sent in the initial INVITE; a re-INVITE must be used for this purpose.
- CANCEL: The CANCEL method is used to terminate pending searches or call attempts. User agent and or Proxy can
generate it.
- OPTIONS: The OPTIONS method is used to query a user agent or server about its capabilities and discover its
current availability. A success class (2xx) response can contain Allow, Accept, Accept-Encoding, Accept-Language,
and Supported headers indicating its capabilities.
- SUBSCRIBE: The SUBSCRIBE method [5] is used by a user agent to establish a subscription for the purpose of
receiving notifications (via the NOTIFY method) about a particular event.
- NOTIFY: The NOTIFY method [5] is used by a user agent to convey information about the occurrence of a particular
event.
- REFER: The REFER method is used by a user agent to request another user agent to access a URI or URL
resource. The resource is identified by a URI or URL in the required Refer-To header field. the REFER is probably
being used to implement a call transfer service.
- MESSAGE: The MESSAGE method is used to transport instant messages (IM) using SIP.
- INFO: The INFO method is used by a user agent to send call signaling information to another user agent with which it
has an established media session. This is different from a re-INVITE since it does not change the media characteristics
of the call. The request is end-to-end, and is never initiated by proxies.
- PRACK: The PRACK method is used to acknowledge receipt of reliably transported provisional responses. A PRACK
is generated by a UAC when a provisional response has been received containing a RSeq reliable sequence number
and a Supported: 100rel header. The PRACK echoes the number in the RSeq and the CSeq of the response in a RAck
header
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP lucasian.trinity.cambridge.edu.uk;branch=z9hG4bK452352;received=1.2.3.4
To: Descartes <sip:rene.descartes@metaphysics.org>;tag=12323
From: Newton <sip:newton@kings.cambridge.edu.uk>;tag=981
Call-ID: <a href="mailto:5@lucasian.trinity.cambridge.edu.uk">5@lucasian.trinity.cambridge.edu.uk</a>
RSeq: 314
CSeq: 1 INVITE
Content-Length: 0
PRACK sip:rene.descartes@metaphysics.org SIP/2.0
Via: SIP/2.0/UDP lucasian.trinity.cambridge.edu.uk;branch=z9hG4bKdtyw
Max-Forwards: 70
CSeq: 2 PRACK
RAck: 314 1 INVITE
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP lucasian.trinity.cambridge.edu.uk;branch=z9hG4bKdtyw ;received=1.2.3.4
CSeq: 2 PRACK
Content-Length: 0
-UPDATE: The UPDATE method is used to modify the state of a session without changing the state of the dialog, used
when offer -answer model (media session) is not completed.
Responses:
- 180 Ringing: This response is used to indicate that the INVITE has been received by the user agent and that alerting
is taken place.
- 181 Call is Being Forwarded: This response is used to indicate that the call has been handed off to another end-
point.
- 182 Call Queued: This response is used to indicate that the INVITE has been received, and will be processed in a
queue.
- 183 Session Progress: A typical use of this response is to allow a UAC to hear ring tone, busy tone, or a recorded
announcement in calls through a gateway into the PSTN.
Headers:
CSeq: The command sequence CSeq header field is a required header field in every request. The CSeq header field
contains a decimal number that increases for
each request. Usually, it increases by 1 for each new request, with the exception of CANCEL and ACK requests, which
use the CSeq number of the INVITE request to which it refers.
From:
The From header field is a required header field that indicates the originator of the request.A From header field may
contain a tag, used to identify a particular call.
Subject:
The contents of the header field can also be displayed during alerting to aid the user in deciding whether to accept the
call.
supported:
The contents of the header field can also be displayed during alerting to aid the user in deciding whether to accept the
call.
Labels: SIP, VOIP (Voice over IP)

0
Add a comment
6th September 2012
M3UA is a protocol for supporting the transport of any SS7 MTP3-User signaling (e.g., ISUP and SCCP messages)
over IP using the services of the Stream Control Transmission Protocol (SCTP). In addition, provision is made for
protocol elements that enable a seamless operation of the MTP3-User peers in the SS7 and IP domains. This protocol
would be used between a Signaling Gateway (SG) and a Media Gateway Controller (MGC) or IP-resident Database.
SG: SG is a Signaling Agent, which interface between the SS7 and IP network. It appears the SS7 SP to the SS7 . SG
is logical entity with contains the one of more SGP.
SGP: SGP is logical instance of SG. SGP is a physical entity, which has the association between to ASP. All SGP within
the SG have the view towards the SS7 Network.
AS: AS is a logical entity, which serves as a specific Routing key. It is present in IP domain. An AS contains set of one
or more ASP. There is 1:1 mapping of AS to routing key i.e. there is one routing per AS.
ASP: ASP is process instance AS. it is physical entity which have association with the SGP. Unlike SGP, An ASP can be
part of one or more AS.
IPSP: IPSP is a process instance of IP-based application. it is same as ASP but not connected to SS7 network via SGP.
When two users are present in IP domain we only need IPSP.
Routing Key: Routing key is set of SS7 parameters and parameter values that uniquely define the signaling traffic to be
handled by particular AS.
Routing Context: RC is a unique identifier of a Routing key. RC can user configurable. The scope of RC is global on
SGP side.
ASP/IPSP SGP/IPSP
===================================
- ASP UP>
INACTIVE State <ASP UP ACK
-ASP ACTIVE>
ACTIVE state <ASP ACTIVE ACK-
BEAT->
<-BEAT ACK-
To make down the M3UA association:
ASP/IPSP SGP/IPSP
=======================================
-ASP DOWN>
<ASP DOWN ACK-
-ASP INACTIVE->
<ASP INACTIVE ACK
MTP 3 User Adaptation (M3UA) - SIGTRAN Stack
Labels: SIGTRAN Stack - M3UA

3
View comments
4th September 2012
SCTP is designed to transport PSTN signaling messages over IP networks, but is capable of broader applications. SCTP is a
reliable transport protocol operating on top of a connectionless packet network such as IP.
It offers the following services to its users:
- Error Free, Non-duplicated transfer of user data.
- Data fragmentation.
- Optional bundling of multiple user message in one single SCTP packet.
- Fault tolerance using the multi-homing.
SCTP provide following features:
- it is transport layer protocol, like TCP and UDP.
- It is unicast protocol communication between 2 endpoint.
- It is session oriented protocol. it creates association between the endpoint. Endpoints are identified by the IP address and
logical port number.
- It provide the multihoming - more than one IP address of one endpoint to provide the multi-path, endpoints are identified by the
port number. Only one path (association) can be active at a given time. multi homing is provided for path failure (redundancy) not
for load sharing.
- Provide the reliable transmission using SACK method. Retransmission take place time out in ACK has the gap in TSN.
- provide the path failure detection using the heartbeat mechanism.
- provide the security consideration using the verification tag and cookies.
- It is message oriented protocol.
SCTP Association initialization
EndPoint-A EndPoint-B
closed state INIT(veri tag, init tag, IP)> Cloesed State
cookie wait state <INIT ACK(init tag,IP,verification tag)-
cookie echoed COOKIE_ECHO (cookie)>
Established state <-COOKIE ACK Established
<DATA-
SACK->
init and init ack must not be bundled with other chunk. if an error received at init/initAck, ABORT is sent.
Handle Stream: Endpoints sends (in init and initACK) the number of outbound stream (OS), and maximum inbound stream. if
peers MIS is less than the endpoints OS, than the endpoint either use the MIS outbound stream, or abort the association.
Shutdown the association:
ENDPoint-A ENDPoint-B
-SHUTDOWN>
<SHUTDOWN ACK
SHUTDOWN COMPLETE>
Chunk: A unit of information within an SCTP packet, consisting of a chunk header and chunk-specific content.
Congestion Window (cwnd): An SCTP variable that limits the data, in number of bytes, a sender can send to a particular
destination transport address before receiving an acknowledgement.
Message Authentication Code (MAC): An integrity check mechanism based on cryptographic hash functions using a secret
key.
Receiver Window (rwnd): An SCTP variable a data sender uses to store the most recently calculated receiver window of its
peer, in number of bytes. This gives the sender an indication of the space available in the receivers inbound buffer.
SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state
information including Verification Tags and the currently active set of Transmission Sequence Numbers (TSNs), etc. An
association can be uniquely identified by the transport addresses used by the endpoints in the association. Two SCTP endpoints
MUST NOT have more than one SCTP association between them at any given time.
SCTP endpoint: The logical sender/receiver of SCTP packets. On a multi-homed host, an SCTP endpoint is represented to its
peers as a combination of a set of eligible destination transport addresses to which SCTP packets can be sent and a set of
eligible source transport addresses from which SCTP packets can be received. All transport addresses used by an
SCTP endpoint must use the same port number, but can use multiple IP addresses. A transport address used by an
SCTP endpoint must not be used by another SCTP endpoint.
Stream Sequence Number: A 16-bit sequence number used internally by SCTP to assure sequenced delivery of the user
messages within a given stream. One stream sequence number is attached to each user message.
Transmission Sequence Number (TSN): A 32-bit sequence number used internally by SCTP. One TSN is attached to each
chunk containing user data to permit the receiving SCTP endpoint toacknowledge its receipt and detect duplicate deliveries.
Transport Address: In the case of SCTP running over IP, a transport address is defined by the combination of an IP address and
an SCTP port number (where SCTP is the Transport protocol).
Verification Tag: A 32 bit unsigned integer that is randomly generated. The Verification Tag provides a key that allows a receiver
to verify that the SCTP packet belongs to the current association and is not an old or stale packet from a previous association.
SCTP Packet Format: SCTP provide the bundling of more than on chunk in one SCTP packet except for the INIT, INIT ACK, and
SHUTDOWN COMPLETE chunks and segmentation if size if giver.
Common Header
|Checksum|Verification Tag| Destination Port Address| Source Port Address|
Source Port Number (16bit, Sender Port Number)
Destination Port Number (16bit, Receiver Port
Verification Tag (32bit, to validate the sender, it should same as initiate tag received in INIT during
the starting the association. in INIT, it should be zero and in SHUTDOWN COMPLETE, it should same as SHUTDOWN-ACK.
- Checksum (CRC32bit, to check the error in packets)
CHUNK header
|value|Length|Type| |value|length|Type| SCTP Common Header|
Chunk Type (8bit, it can be init, initack, shutdown, heartbeat, etc)
Stream Control Transmission Protocol (SCTP)
- Chunk Flags (8bit, depend on chunk type, otherwise zero)
- Chunk Length (16bit, provide the length of chunk including the headers)
Chunk Value (varaible length, actual data Payload)
INIT Chunk: |Type=1|Chunk Flags|Chunk Length|Initiate tag|a_rwnd|Number of OS|Number of IS|Initial TSN|optianal Param|
SCTP Features:
- Transport Layer Protocol - Alternative to TCP and UDP.
- Uni-cast Protocol - Communication between the 2 end points.
- Session Oriented - "associated" between 2 endpoints.
End points are identified by the near and far end IP address and logical Address.
Supports Multi-homing (Association composed evenly of several paths). Only path active at a time(Unicast)
paths are monitored to defects failures uses Heartbeat Mechanism.
- Message Oriented - not byte-oriented like the TCP. Byte- oriented transport having the problem all messages
are transferred in single stream so that if error occurs, TCP holds up delivery of all data. While SCTP supports
message oriented data transfer in multi stream fashion which insures if errors occurs at one stream there would be no impact on
transmission of other streams data.
[http://1.bp.blogspot.com/-0O56igaFhwg/UEWd1M7_zUI/AAAAAAAAAGI/ovcLvZQkp6M/s1600/multistreamed.JPG]

Define structured frames of data
Allow to encapsulate upper layer within the SCTP message.
- Reliable Delivery: undelivered messages are re-transmitted.
Using Sequenced acknowledges (SACK)
TSN (Transmission sequence numbers) are used to provide reliable delivery.
Retransmission takes places if: 1.Timeouts 2. Ack has gap in TSN.

[http://4.bp.blogspot.com/-1z55tffCkG4/UEWfB2pvtkI/AAAAAAAAAGQ/7F7hOFsE2fE/s1600/sctp_features.JPG]

Labels: SIGTRAN

0
Add a comment
4th September 2012
SIGTRAN (Signalling Transport) is a set of protocols defined to transport SS7 messages over IP networks.
SIGTRAN
GjPvWnulWwE/UEWkth1UhUI/AAAAAAAAAGo/T3fLdFrEXbQ/s1600/sig.JPG]
SIGTRAN allows IP networks to inter-worked with the Public switched Telephone Network (PSTN) and vice-versa.
[http://3.bp.blogspot.com/-ZOEmaQpWYMQ/UEWTnRouBXI/AAAAAAAAAFY/JiRUDCBNrUs/s1600/sigtran.JPG]
The Sigrtan protocol stack based on following components:
[http://4.bp.blogspot.com/-m3veyev1Ros/UEWUzlJSPPI/AAAAAAAAAFg/jHkKW7zb-u8/s1600/sigtran-component.JPG]
- A Standard IP stack.
- A common signalling transport protocol, that we called as SCTP (stream transmission Protocol)
- Adaptation Layer: These are the Adaptation layers for MTP2, MTP3 and ISUP, called M2PA, M2UA, M3UA, and SUA.
SIGTRAN Stack:
[http://3.bp.blogspot.com/-5ONMD2JDl3k/UEWXicXCeXI/AAAAAAAAAF4/cH8X7eKxaUM/s1600/sigtran_stack.JPG]
Labels: SIGTRAN

0
Add a comment
3rd September 2012
Intelligent Networks (IN):-
Intelligent Networks is a concept service intelligence resides in a central node called an SCP and SSPs (residing on Switches)
relinquish control to this node at particular stages in a call so that appropriate service logic can be applied.
Objectives of IN:
- Increased Service Velocity / Speed of Deployment
- Increased Range of Services
- Evolvability from Existing Networks
- Service & Vendor Independent Implementation
- MSC just focuses on core job of call processing
Network Before IN: Before IN application, there was messed network for every node:
Intelligent Networks (IN) and CAMEL
JhjEnqT-8Vo/UEXP_08WKfI/AAAAAAAAAHA/ngDfIt1n4m0/s1600/cap.JPG]
[http://4.bp.blogspot.com/-vG-
KnLdSBIg/UERY1QTItII/AAAAAAAAABo/0W9Y2WqBfNI/s1600/preIN.JPG]
Network with IN: After IN implementation, Network is organised.
g8k21TsuzF8/UERZLx_m1bI/AAAAAAAAABw/hu_XQ_9wkLw/s1600/postIN.JPG]
Basic Concepts PIC and DPs & BCSM:
Point In Call (PIC) : A state in a basic call state model.
Detection Point (DP) : A point in basic call processing at which specific event is detected. Detection Points
represent transitions between points in call processing (PICs). There are two types of DPs: TDP and EDP. EDP is
also of two Type.
-Trigger Detection Point (TDP): statically armed DP at which the MSC/SSP first contacts the SCP to request for
instructions or to provide information about call events. Processing is suspended when the DP is encountered.
-Event Detection Point -Notification (EDP-N): An EDP is a dynamically armed DP that is armed by the SCP. The
call processing point at which the MSC/SSP must contact the SCP to notify it of an event. Processing is not
suspended when encountering the DP.
- Event Detection Point Request (EDP-R): This detection point is dynamically armed within the context of a
CAMEL control relationship. Processing is suspended when encountering the DP and the gsmSSF waits for instructions
from the gsmSCF.
- Service Switching Function (SSF) This is co-located with the MSC itself, and acts as the trigger point for further
services to be invoked during a call.
- Service Control Function (SCF) This is a separate set of platforms that receive queries from the SSP.
- Service Data Function (SDF) This is a database that contains additional subscriber data, or other data required to
process a call.
- 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, for example play voice announcements or collect
DTMF tones from the user.
Customized Applications for Mobile networks Enhanced Logic, or CAMELfor short, is a set of standards
designed to work on either a GSM core network or UMTS network. They allow an operator to define services over and
above standard GSM services/UMTS services. The CAMEL architecture is based on the Intelligent Network (IN)
standards, and uses the CAP protocol and it is particularly effective in allowing these services to be offered when a
subscriber is roaming.
CAMEL Network Structure:
CSI identifies if the subscriber requires CAMEL support. CSI identifies which gsmSCF to use for that CAMEL support.
CSI contains information related to the Operator Specific Service (OSS) of the subscriber, for example the Service Key.
Originating-CSI identifies subscriber as having originating CAMEL Services. O-CSI is stored in the VLR as part of
subscriber data for roaming subscriber in the VLR area.
Terminating-CSI identifies subscriber as having terminating CAMEL Services. T-CSI is fetched by the GMSC when the
HLR of the called subscriber is being interrogated by the GMSC. Originating-CSI is sent to the GMSC for forwarding.
CSI CONTENT -
gsmSCF address: as an E.164 number
Service Key : which identifies to the gsmSCF the service logic that should be used.
Default call handling: that indicates how to proceed the call in case of error in the dialogue (release or continue).
TDP list: that indicates on which Detection Point (DP) triggering shall take place. Only DP2 for O-CSI and only DP12 for
T-CSI.
DP2/ DP3 Trigger Detection Point:
A-Party MSC VLR SCP B-Party
============================================================
Setup>
SIOC(IN)->
<Complete Call(IN)
INITDP(2)>
<Continue-
SIOC(No IN)->
<Complete Call
<Call Proc/Assnmt->
IAM>
[http://3.bp.blogspot.com/-Ny-
Dyca_hRU/UERZ7e9wIBI/AAAAAAAAAB4/s8dbmdPmVOc/s1600/dp2.jpg]
DP2 (OCSI)
Service Screened in first SIOC: COS, ODB (BAOC & BAOC roaming outside the HPLMN Country), BAOC, CUG, IN (O-CSI)
Service screened in second SIOC: Remaining flavos if ODB and barring, LCO, OSSP screening.
DP12 Trigger Detection Point:
A-Party MSC HLR SCP B-Party
============================================================
IAM>
SRI->
<SRI ACK(IN)
INITDP(12)>
<CONTINUE-
SRI->
<SRI ACK
Paging >
pnD7BUHrEAs/UERahsyuBwI/AAAAAAAAACA/q1SGjqC8B2c/s1600/dp12.jpg]
Service screened in 1st SRI: DP12
Service screened in 2ndSRI: except IN all service.
DP2 on Forwared forwarding Leg: In Call Forwarding, subscriber A calls subscriber B, who forwards the call to subscriber C.
The forwarding leg to C is seen as a call origination (from B) as opposed to call termination of the call originated by A.
A-Party MSC-A HLR SCP PSTN
=================================================================
IAM>
SRI->
<-SRI ACK(CFU & OCSI)
-INITDP(2)>
<-CONTINUE-

IAM>
YMPkS7WSFZA/UERas9SAAbI/AAAAAAAAACI/xjcGACgZ51w/s1600/dp2_CF.jpg]
DP2 and DP12 on Forwarded forwarding Leg: In this example the subscriber B has been provisioned with both T-CSI service
and O-CSI service. To simplify the diagram, the Terminating service makes no modification to the call set up and the Originating
service is used to modify the CLI of the outgoing leg.
==================================================================
IAM>
SRI>
<-SRI ACK(CFU,TCSI & OCSI)
-INITDP(12)>
<CONTINUE-
INITDP(2)>
<CONNECT-
-IAM>
Applying O-CSI to a call forwarded by CAMEL (T-CSI) : CAMEL can be used to forward calls, instead of using GSM Call
Forwarding. It is possible to apply an O-CSI CAMEL service to the outgoing leg created by a CAMEL forwarding service.
===================================================================
IAM>
SRI->
<-SRI ACK (TCSI & OCSI)
-INITDP (12)->
<-CONNNECT(DRA + OCSI)
INITDP(2)>
<CONNECT(CLI Modified)-
IAM(with modified CLI)>
ANSWER Event Detection Point- Notify:
A-Party MSC HLR SCP PSTN
==================================================================
IAM>
SRI->
<-SRI ACK(TCSI )
INITDP(12)>
<-RRBE(EDP, T_Answer)
CONNECT(PSTN)->

-IAM->
<-ACM <-ACM
<-ANM <-ANM ERB
->
Disconnect Event Detection Point- Request:
A-Party MSC HLR SCP PSTN
=================================================================
IAM>
SRI>
<-SRI ACK(TCSI )
-INITDP(12)>
<-RRBE(EDP, T_Answer)
CONNECT(PSTN)->

-IAM->
<-ACM <-ACM
<-ANM <-ANM-
REL->
-ERB>
<Continue
-REL>
<-REL
<RLC-
External IP Connection:
A-Party MSC VLR SCP IP MS
================================================================================
setup>
SIOC->
<Continue(OCSI )-
INITDP(2)>
<ETC(IP)

-PRI Connection Established>
<-DFC
<-PRI Connection Trerminated
<Continue
-Paging>
Example of VPN: An example of MO CAMEL Phase 1 service is VPN. User A subscribes to VPN, the CSI (stored in the HLR) is
copied to the VLR at Location Update. After dialing a short number (1) (e.g.colleagues extension), the call is stopped by the SSF
which requests instructions from the SCF (2). The SCF gives the SSF the full number (3) that the VMSC uses to route the call to
the GMSC (4).
Callee VMSC SCP GMSC
================================================================================
Setup(1234)>

-INITDP(1234)>
<-CONNECT(0122334343)

IAM>
An example of an MT CAMEL Phase 1 service is Time Dependent Routing (TDR). A subscriber can decide where his calls will be
routed depending on the period of the month/ week or even the time of the day (e.g. to his mobile, voice mail, secretary fixed line).
When the GMSC receives the called party CSI (6),the SSF stops the call to request instructions from the SCF (7).The SCF
provides routing information to the SSF so that the call is routed to the subscribers mobile since he is willing to accept calls at
this time of the day (8).
Within CAMEL we are CAMEL Phase 1 compliant. Hence all the following CAMEL Phase 1 operations are available currently in
the MSC/SSP:
ActivityTest
Connect
Continue
EventReportBCSM (ERB)
InitialDP
ReleaseCall
RequestReportBCSMEvent (RRBE)
The following new operations are implemented to support CAMEL Phase 2:
ETC (EstablishTemporaryConnection)
DFC (DisconnetForwardConnection)
FCI (FurnishChargingInformation)
ResetTimer
ApplyCharging (AC)
ApplyChargingReport (ACR)
Send Charging Information (SCI)
Play Announcement
Connect To Resource (for SRF)
Prompt and Collect User Information
Call Information Request (CIR)
Call Information Report
IEs:
Initial DP (IDP):- from gsmSSF to gsmSCF to collect the information
Called PartyNumber
Calling party Number
Calling Party category
Location Number
Original Called Party ID
Additional CallingParty Numer
Bearer Capability
Redirection PartyID (Redirection Number)
IMSI
Location Information
ext-Basic Service Code
Callforwarding SS Pending
MSC Address
time and timezone
carrier
service key (m)
highLayer capability (HLC)
eventtype BCSM
Redirection Information
subscriber state
cug-index/cug-interlock/cug-OutgoingAccess
High Layer Capability (HLC)
CONNECT:- from gsmSCF to gsmSSF to connect to new number.
Destination Routing Address (DRA)
Alerting Pattern
Original Call party ID
carrier
Calling Party Category
Redirection Party ID
Redirection Info
Generic Number
charge number
supperssion of annoucement
oCSI Applicable
Activity Test:- AT is used to check for the continued existance of a relationship between the gsmSCF and gsmSSF. no IE.
Apply Charging:- from gsmSCF to gsmSSF, charging mechanisms to control the call duration.
-ACh Billing Charging Characteristics:- Time Duration Charging:- Max call period Duration, Traffic Swtch Interval, Release if
duration exceeds.
-Party to Charge
Play Tone
Call Information Request (CIR):- from gsmSCF to gsmSSF to record speceific information about call and report it.
-Request Information Type List (Call Attempt Elapsed Time, Call Stop Time, Call Connected Elapsed Time, release Cause)
-Leg ID
Cancel:- from gsmSCF to gsmSSF to cancel all EDPs and report.
- All Request
Connect To Resource (CTR): used to connect from gsmSSF to gsmSRF.
- Service Intraction Indicators Two
- Resource Address ( IP Routing Address, None)
Continue: from gsmSCF to gsmSSF to continue the basic call flow that was suspended.
Disconnect Forward Connection (DFC): to dissconnect the connection with gsmSRF connect with CTR IF.
Establish Temporary Connection (ETC): used to connection from gsmSSF to assisting gmsSSF as a part of assist procedure.
can also be used to create connection between the gsmSSF and gsmSRF.
- Assisting IP Routing Address
- Correlation ID
- Carrier Information
- Originating Line Information
- scf ID
Comparison of O-BCSM DPs in the Ph1 and Ph2:
[http://4.bp.blogspot.com/-QN13cscJ0L8/UERcPALKbcI/AAAAAAAAACY/hhuX03krof8/s1600/comparison_ocsi_table.jpg]
Comparison of T-BCSM DPs in the Ph1 and Ph2:
[http://4.bp.blogspot.com/-64eMPhL7UoA/UERcWSe7VSI/AAAAAAAAACg/D8DCm2wX1xY/s1600/comparison_table.jpg]
Posted 3rd September 2012 by Pramod
Labels: Camel, CAP, IN, INAP, SS7 Protocol Stack

0
Add a comment
3rd September 2012
UaLxssk5-kA/UESDKLQSYhI/AAAAAAAAADA/Ly_yINrXmWU/s1600/map.JPG]
MAP (Mobile Application Part):
MAP is the protocol is to used to allow the GSM network nodes within the NSS to communicate with the each other to
provide the service, such as roaming, SMS, Subscriber authentication. MAP is transported and encapsulated with the
SS7 protocols MTP, SCCP, and TCAP.
MAP Phase 2 operations can be divided into the following main categories:
Mobility Management
Operation and Maintenance
Call Handling
Supplementary Services
Short Message Service
MAP (Mobile Application Part)
Mobility Management:
Mobility management operations can be divided into the following categories:
Location Management
Paging and Search
Access Management
Handover
Authentication Management
Security Management
IMEI Management
Subscriber Management
Identity Management
Fault Recovery
Location Management:
To minimize transactions with the HLR, it only contains location information about the MSC/VLR to which the subscriber
is attached.The VLR contains more detailed location information, such as the location area in which the subscriber is
actually roaming. VLR requires that its location information be updated each time the subscriber changes location
area.The HLR only requires its location information to be updated if the subscriber changes VLR.
Location management operations include the following:
updateLocation - Message used by VLR to inform the HLR about change in VLR area.
cancelLocation - The cancelLocation operation is used by HLR to delete a subscribers profile from the previous VLR
sendIdentification - the new VLR queries the old VLR using a sendIdentification operation to obtain authentication
information. The sendIdentification operation sends the TMSI as its argument, and the result contains the IMSI and
other authentication information (RAND, SRES, and optionally KC). If it is unable to obtain this information, it can
retrieve the information from the HLR via a sendAuthenticationInfo operation.
purgeMS - This message is sent if an MS has been inactive (no call or location update performed) for an extended
period of time. The VLR sends this message to the HLR to indicate that it has deleted its data for that particular MS.
Handover:
The following sections describe MAP handover operations:
prepareHandover - The prepareHandover message is used to carry a request and response between the two MSCs
at the start of a basic inter-MSC handover
sendEndSignal - Following a successful inter-MSC handover (from MSC-A to MSC-B in the case of a basic handover),
MSC-B sends a sendEndSignal message to MSC-A to allow it to release its radio resources
processAccessSignalling -
forwardAccessSignalling
prepareSubsequentHandover - If another inter-MSC is required (back to MSC-A or to another MSC, C), then MSC-
B sends this message to MSC-A. It contains the information required for MSC-A to send a prepareHandover message
to MSC-C
Authentication Management:
MAP operation sendIdentificationInfo is the only operation in Phase 2 that falls under the category of authentication
management..
IMEI Management:
The only MAP operation in the IMEIs management category is checkIMEI, which is used to check whether a piece of
mobile equipment is on a black, gray, or white list. the MSC sends the IMEI to the EIR in a MAP checkIMEI operation.
The EIR checks the status of the IMEI and sends the result back to the MSC.
Subscriber Management:
An HLR uses subscriber management procedures to update a VLR with specific subscriber data when the subscribers
profile is modified. A subscribers profile can be modified, because the operator has changed the subscription of the
subscribers basic services or one or more supplementary services.
- insertSubscriberData: The HLR uses the insertSubscriberData operation to provide the VLR with the
current subscriber profile
- deleteSubscriberData: The HLR uses the deleteSubscriberData operation to inform the VLR that a service has been
removed from the subscriber profile.
- restoreData: When a VLR receives a provideRoamingNumber request from the HLR for either an IMSI
that is unknown to the VLR or an IMSI in which the VLR entry is unreliable because of an HLR outage, the VLR sends a
restoreData message to the HLR to synchronize the data.
Call Handling:
Call handling does not have subcategories of operations; it simply has the following two operations:
sendRoutingInfo - The GMSC then identifies the subscribers HLR based on the MSISDN, and invokes the MAP
operation sendRoutingInformation with the MSISDN as a parameter towards the HLR to find out where the MS is
presently located.
provideRoamingNumber - Because of past location updates, the HLR already knows the VLR that currently serves the
subscriber. To obtain a mobile station roaming number (MSRN), the HLR queries the VLR using the operation
provideRoamingNumber with the IMSI as a parameter. The VLR assigns an MSRN from a pool of available numbers
and sends the MSRN back to the HLR in an acknowledgement.
Supplementary Services:
Supplementary services includes the following operations:
registerSS - The registerSS operation is used to register a supplementary service for a particular subscriber.
eraseSS - EraseSS is used to delete a supplementary service that was entered for a particular subscriber using
registerSS.
activateSS - ActivateSS is used to activate a supplementary service for a particular subscriber.
deactivateSS - This operation switches off a supplementary service for a particular subscriber;
interrogateSS - InterogateSS allows the state of a single supplementary service to be queried for a particular
subscriber in the HLR.
registerPassword - This operation is used to create or change a password for a supplementary service. When the
HLR receives this message, it responds with a getPassword message to request the old password,
getPassword - The HLR sends this message if the subscriber wants to change his current password or modify or
activate a supplementary service.
Unstructured Supplementary Services (USSs):
USSs allow PLMN operators to define operator-specific supplementary services and to deliver them to market quickly.
The communication is carried out using Unstructured supplementary service data (USSD)
data packets,Unlike SMS, which is based on a store and forward mechanism, USSD is session oriented and, therefore,
has a faster turnaround and response time than SMS, which is particularly beneficial for interactive applications. USSD
can carry out the same two-way transaction up to seven times more quickly than SMS can.
Short Message Service (SMS): It has the following operations:
forwardSM
sendRoutingInfoForSM
reportSMDeliveryStatus
readyForSM
alertServiceCentre
informServiceCentre
Posted 3rd September 2012 by Pramod

0
Add a comment
2nd September 2012
TOkLnJpAI6Q/UEHRJMz4n2I/AAAAAAAABPA/FQoQGyzIugQ/s1600/isup.JPG]
Questionnaire on ISUP:
1.) Define the call flow for ISUP call.
2.) What is terminating party on-hook the calls. Is the call dropped?
3.) What is CIC. Is it necessary to have same CIC value at both end, why?
4.) Define the type of Address Signaling.
5.) What is circuit glare condition. How to remove and avoid the glare condition.
6.) What is continuity test (COT)?
7.) define the Message structure of ISUP.
8.) Provide the message element of IAM, ACM, ANM, REL, RLC, COT...
Answers:
1.) ISUP allows the call control signaling to be separated from the circuit that carries the voice stream over interoffice
trunks.
ISUP call scenario:
A-Party B-Party
IAM--------------------------------->
COT--------------------------------->
<------------------------------------ACM
<------------------------------------ANM
REL---------------------------------->
<------------------------------------RLC
ISUP (ISDN User Part)
2.) If the terminating party goes on-hook first, the call might be suspended instead of being released. Suspending a call
maintains the bearer connection for a period of time, even though the terminator has disconnected. The terminator can
go off-hook to resume the call, providing that he does so before the expiration of the disconnect timer or a disconnect
by the originating party.
3.) Circuit Identification Codes (CIC): One of the effects of moving call signaling from CAS to Common Channel
Signaling (CCS) is that the signaling and voice are now traveling on two separate paths through the network.ISUP uses
a Circuit Identification Code (CIC) to identify each voice circuit.Because the CIC identifies a bearer circuit between two
nodes, the node at each end of the trunk must define the same CIC for the same physical voice channel.
4.) Address Signaling in ISUP are two types:
- Enblock Signaling: The enbloc signaling method transmits the called part number as a complete entity in a single
message. When using enbloc signaling, the complete number is sent in the IAM to set up a call.
-Overlap Signaling: Overlap signaling sends portions of the number in separate messages as digits are collectedfrom
the originator.When using the overlap method, the IAM contains the first set of digits. The Subsequent Address
Message (SAM) is used to transport the remaining digits.
5.) Circuit glare (also known as dual-seizure) occurs when the node at each end of a two-way trunk attempts to set up a
call over the same bearer at the same time. Using ISUP signaling, this occurs when an IAM for the same CIC is
simultaneously sent from each end. Each end sends an IAM to set up a call before it receives the IAM from the other
end.
To remove the Glare Condition, one node must back down and give control to the other end.
For avoiding the glare condition, common method is to perform trunk selection in ascending order of the trunk member
number at one end of the trunk group, and in descending order at the other end. Another method is to have one end
use the Most Idle trunk selection while the other end uses the Least Idle selection.
6.) Continuity Test: Continuity testing verifies the physical bearer facility between two SSPs. When CAS signaling is
used, a call setup fails if the voice path is faulty. Using ISUP signaling, it is possible to set up a call using the signaling
network without knowing that the bearer connection is impaired or completely broken. originating exchange determines
whether a continuity test should be performed.
7.) ISUP message same as SCCP with CIC associated with it.
- CIC
- Message Type
- mandatory Fixed Part (only content)
- Mandatory Variable Part ( have length and value)
- Optianal Part (have name, length and content)
Posted 2nd September 2012 by Pramod

0
Add a comment
2nd September 2012
mSZsK87KaHo/UEHQvj37ciI/AAAAAAAABO4/3AcTv8ouRuI/s1600/tcap.JPG]
Questionnaire on TCAP:
1.) Why use TCAP, what is the sublayers of TCAP.
2.) define the ITU and ANSI TCAP message type?
3.) Define the components portion.
4.) define dialogue portion?
5.) define the Error handling on TCAP.
Answers:
1.) TCAP is used for Non-Circuit related signaling, to retrieve the information from the database in form of dialogue of
question and answer. TCAP does not have any transport facility so it use SCCP transport to transfer the message.
TCAP (Transaction Capabilities Application Part)
TCAP message is composed of following two main section:
transaction Sublayer: A translation is set of related TCAP messages that are exchanged between the network nodes.
The transaction portion identifies the messages that belong to the same transaction identifier (TRID).
component Sublayer: The messages' component portion contains the actual instruction i.e. "opeartion" that are being
to sent to remote application.
2.) ITU TCAP Message:
- Unidirectional (TIDpresent: No TID): Sent in one direction and expects no reply
- Begin (TIDpresent: OTID): Start a transaction
- End (TIDpresent: DTID): Ends the Transaction
- Continue (TIDpresent: OTID, DTID): Continues an established transaction
-Abort (TIDpresent: DTID): Sent to notify the transaction is aborted due to some cause like protocol error.
ANSI TCAP Message:
- Unidirectional (TIDpresent: No TID): Sent in one direction and expects no reply
- Query with permission (TIDpresent: OTID): start the transaction , giving the permission to receiving node to end the
transaction
- Query without permission (TIDpresent: OTID): start the transaction , No permission to receiving node to end the
transaction
- Conversation with permission( TIDpresent: OTID, DTID)): continues a transaction , giving the permission to receiving
node to end the transaction
- Conversation without permission( TIDpresent: OTID, DTID)): continues a transaction , No permission to receiving
node to end the transaction
-Abort (TIDpresent: DTID): Sent to notify the transaction is aborted due to some cause like protocol error.
3.) Components are a means of invoking an operation at a remote node. A TCAP message can contain several
components, thereby invoking several operations simultaneously.
Following four Operational Protocol Data Units (OPDUs):
- Invoke - Requests an operation to be performed
- Return Result - Reports the successful completion of a requested operation
it is further divided in
1. Return result last - The Return Result Last indicates that an operations final result has been returned.
2. Return result not Last. - The Return Result Not Last indicates that further results will be returned
- Return Error - Reports the unsuccessful completion of a requested operation
- Reject - Reports a protocol violation, such as an incorrect or badly formed OPDU
The contents of the components include the following information:
Component Type
Component ID- message can contain several components. Each Invoke Component is coded with a numeric Invoke
ID, which must be unique for each operation in progress because the ID is used to correlate the exchange of
components for a particular operation.
Operation Code (Invoke Component only)/ Error/Problem code (Return error/reject)
Parameters - Components can have parameters associated with them. The parameters are the data that is
necessary to carry out the operation requested by the component Operation Code. For example, a component
containing a Play Announcement Operation Code also contains an announcement parameter. The announcement
parameter typically provides the announcement ID so the correct recording is played to the listener.
4.) Dialogue Portion :It establishes a flow of information within a particular context for a transaction. Information, such
as the protocol version and application context, is used to ensure that two nodes interpret the component sublayers
contents in the same manner using an agreed upon set of element definitions.
ITU Dialogue:
There are two categories of dialogues:
- structured - A structured dialogue requires a reply.
- unstructured. An unstructured dialogue is one in which no reply is expected. This type of dialogue uses a
Unidirectional message type at the transaction layer.
The following are four types of APDU (Application protocol date unit):
Dialogue Request - The Dialogue Request consists of an Application Context Name and, optionally, Protocol Version
and User Information. It is used to request dialogue information from another node
Dialogue Response - The Dialogue Response is sent as a reply to a Dialogue Request.
Dialogue Abort
Dialogue Unidirectional - The Unidirectional Dialogue consists of an Application Context Name and optional Protocol
Version and User Information. It is used to convey dialogue information in one direction, for which no reply is expected.
5.) TCAP errors falls into three catogory:
- Protocol Errors: Protocol Errors are the result of TCAP messages being incorrectly formed, containing illegal values,
or being received when not expected. example of an error would be receiving a responding Transaction ID for a
nonexistent transaction.
- Application Errors: Application Errors are anomalies within the application procedure.example is a missing customer
record error, which is an error that is used to indicate that a database lookup failed to find the requested information.
- End-User Errors - The End-User Error is similar to the Application Error in that it is an anomaly of the application
procedure. However, as indicated by the name, the anomaly is the result of some variance from the normal actions by
the user. The user might take an action, such as abandoning the call prematurely.
Posted 2nd September 2012 by Pramod

0
Add a comment
1st September 2012
[http://1.bp.blogspot.com/-pZ-
d3barj4I/UEHO6nSJ95I/AAAAAAAABOw/8hdT1YRp9i0/s1600/sccp.JPG]
Questionnaire on SCCP:
1.) What are the benefit of SCCP over the MTP, which protocols uses the SCCP.
2.) Define the SCCP architecture and functional Area.
3.) Why we use XUDTS/UDTS messages.
4.) Define the connection oriented Message.
5.) Define the Connection Less messages.
6.) define SCCP Message structure.
7.) structure of CR,CC, CREF, UDT,UDTS,DT ?
8.) define GT and GTT?
9.) What is AI?
10.) Explain the User Data and Segmentation.
11.) What is TI value and TI Flag.
==========================
Answers:
1.) Benifits of SCCP over the MTP:
- Provide the Segmentation and reassemble when message is large for 1 MSU.
- Provide more flexible routing using the Global Tittle (GT)
- Used for both Connection-less and connection-oriented data transfer.
- Provide management and addressing of Subsystem.
Uses:
- SCCP is used extensively in cellular networks. BSSMAP and DTAP use it to transfer the radio related messages in
GSM.
- In conjection with the TCAP, SCCP is also used throughout the GSM NSS to transport MAP signaling between the
core GSN components.
2.) SCCP functional areas:
- SCCP Connection-oriented Control (SCOC) - responsible for setting up and releasing the virtual connection between
two SCCP users
- SCCP Connection-less control (SCLC) - responsible for transferring the data b/w the users without using the virtual
connection. Primarly used by TCAP.
- SCCP Routing Control (SCRC) - provide the routing beyond the MTP, through the use of the global title.
- SCCP Management (SCMG) responsible for tracking the application status and informing the SMG at other SCCP
node.
Application that uses the service of SCCP are called Subsystems.
Classes of service:
Class 0Basic connectionless class - it has no sequencing control. i does not impose any condition on SLS,
therefore SCCP message can be delivered in out-of-sequece.
Class 1In-sequence delivery connectionless class - it adds the sequence control to class 0 service by requiring to
insert the same SLS to all NSDU.
SCCP (Signalling Connection Control Part)
Class 2Basic connection-oriented class - Assign the local reference numbers (SLR,DLR) to create logical
connection. it does not provide the flow control, loss, and mis-sequence detection.
Class 3Flow control connection-oriented class - Class 3 is an enhanced connection-oriented service that offers
detection of both message loss and mis-sequencing
3. ) UDTS and XUDTS used for the Negative Ack for the UDT and XDT respectivily. It indicates to the originating SCCP
that a UDT message that is sent cannot be delivered to its destination.
4.) Connection Oriented Messages: CR, CC, CREF, DT1, DT2, RLSD, RLC, AK ( Data Ack), ED (expedited Data), EA
(expedited Data Ack), RSR (Reset Request), RSC (Reset Confirm), IT (Inactivity Test).
5.) Connection Less Messages: UDT, UDTS, XUDT, XUDTS, LUDT, LUDTS.
6.) Apart from CIC, SCCP message structure is same is ISUP messages. Refer
the http://telecomprotocols.blogspot.com/2012/09/sccp-messages.html
[http://telecomprotocols.blogspot.com/2012/09/sccp-messages.html] for the complete coverage of sccp message.
- mandatory Fixed Part: because it mendory and are of fixed length so length required. type and order is known so no
parameter name required (only value is required). Usally Message Type, SLR, and Protocol Class are in MF Part.
- Mandatory variable Part: only Length and value are required. No Tag required. Usally Called Part Address is in MV
Part.
- Optional Part: Tag, Length and Value are required. One Octet END of Optional Parameter field is placed at end of
last optional parameter. it is simply coded as all zeros. Usally Calling Party Address, etc in Optional Part.
7.) Connection Request:
- Message Type
- SLR
- Protocol Class
- Called Party Address
- Calling Party Address
- MCC/MNC/LAC/Cell ID/IMSI
Connection Confirm:
- Message Type
- SLR
- DLR
- Protocol Class
Connection Refused (CREF):
- Message Type
- DLR
- Refusal Cause
- Data
Released (RLSD):
- Message Type
- DLR
- SLR
- Refusal Cause
- Data
Release Complete (RLC):
- Message Type
- SLR
- DLR
Data Form1 (DT1)
- Message Type
- DLR
- Segmentation/Reassembling
- Data
Unit Data ( UDT):
- Message Type
- Protocol Class
- Called Party Number
- Calling Party Number
- Data
Unit Data Service ( UDTS ):
- Message Type Code
- Return Cause
- Calling Party Address
- Data
8.) A global title is an address, such as dialed-digits, which does not explicitly contain information that would allow
routing in the SS7 network. A GT is a telephony address. As such, the GT address must be translated into an SS7
network address (DPC+SSN) before it can be finally delivered.
GTT is an incremental indirect routing method that is used to free originating signaling points from the burden of having
to know every potential application destination (that is, PC+SSN).
If the GTT function results in a "routing indicator" equal to "Route on GT", then the GTT function must provide a global
title and the DPC of the SCCP node where that global title will be translated. This process shall be repeated until the
GTT function results in a "routing indicator" equal to "Route on SSN", which means that the final destination has been
determined.
9.) Address Indicator (AI): AI is the first field within CgPA/CdPA and is one octet in length. Its function is to indicate
which information elements are present so that the address can be interpreted.
| Network Indicator (1 bit) | Routing Indicator (1bit) | GT Indicator (4bit) | SSN Indicator (1bit) | PC Indicator (1bit)|
GT Indicator:
(0000 = GT Not Included,
0001 = GT Includes Nature of Address,
0010 = GT Includes Translation Type,
0011 = GT Includes Translation Type, NP, and Encoding Scheme),
0100 = GT Includes TT, NP, ES, and NOA Indicator)
Routing Indicator:
- Route on GT
-Route on PC +SSN
10.) The data (from subsystems) is sent in information elements called Network Service Data Units (NSDUs). SCCP
provides the capability to segment or reassemble an NSDU that is too large to fit in a single MTP message (MSU) so
that it can be transmitted over a number of MSUs (16 maximum).
When using the connectionless classes, if an NSDU is greater than 255 octets when using a UDT message or 254
when using a XUDT message, the originating node splits the NSDU into a number of XUDT messages.
If an NSDU is greater than 255 octets when using the connection-oriented classes, the originating node splits the NSDU
into several DT messages.
11.) The combination of TI value and TI flag is used to uniquely identify the separate transaction. It is widely important
in Multiparty call, call waiting, call hold where more than one call established at a time.
TI (Transaction Identifier) Flag: This is flag to identifies the originator of the transaction.
For example flag 0 is used for the message is sent from the site that originates the TI.
while flag 1 used for the message is sent to the site that originates the TI.
TI (Transaction Identifier)Value: This is value that has been assigned by the originator of transaction at the start of
transaction to uniquely identify the separate transactions. A available TI value is assigned to this transaction and it
remains fixed to this transaction for its lifetime and made free while the transaction ends.
For Example for the scenario: Mo-A calls Mo-B. Mo-B is having call hold and call waiting. Mo-C calls to Mo-B. Mo-B
holds the Mo-A and retrieve the Mo-C. Mo-B disconnects Mo-C and retrieve Mo-A. And Mo-B Disconnect Mo-A.
The TI value and Flag should be as follows for the above scenario:
Mo-A {0,0 (TI flag,value)} Calls Mo-B {1,0 ( TI flag,value)}
Mo-C {0,0 ( TI flag,value)} Calls Mo-B {1,1 ( TI flag,value)}
Mo-B {1,0 ( TI flag,value)} Holds Mo-A {0,0 (TI flag,value)}
Mo-B {1,1 ( TI flag,value)} Connects Mo-C {0,0 (TI flag,value)}
Mo-B {1,1 ( TI flag,value)} Disconnect Mo-C {0,0 (TI flag,value)}
Mo-B {1,0 ( TI flag,value)} Retrieve Mo-A {0,0 (TI flag,value)}
Mo-B {1,0 ( TI flag,value)} Disconnect Mo-A {0,0 (TI flag,value)}

Posted 1st September 2012 by Pramod

0
Add a comment

SIP Response Codes and Their Meanings

Caricato da

Informazioni sul documento

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

SIP Response Codes and Their Meanings

Caricato da

Copyright:

Formati disponibili

7/7/2014 The Telecom Protocols

Potrebbero piacerti anche