All Protocol Docs

7/7/2014

The Tel ecom Pr otocol s

The Telecom Protoc…

search

Classic

21st March 2013

SIP Responses

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 Client Err or or - 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. 2xx—Successful 2xx—Suc cessful Response s 200 OK: Indicates OK: Indicates the request was successful. 202 Accepted: Indicates that the request has been accepted for processing, but the processing has not been completed. com pleted. 204 No Notification : Indicates the request was successful, but the corr esponding response wil willl not be r eceived. 3xx—Redirection 3x x—Redirection Response 300 Multiple Choice s: 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 updat e any records o f the original Reque st-URI with the new value. 302 Moved Temporarily: The 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. Dynamic V iew s template. Template Template images by chu chuwy wy . Pow Pow ered by Blogger . 380 Alternative Service : The call failed, but alternatives are detailed in the message body. 4xx—Client Failure Responses 400 Bad Reque st: The request could not be understood due to malformed syntax. 401 Unauthorized: The Unauthorized: The request requires user authentication. This response is issued by UASs and registrars. Reserved for future use. 402 Payment Payment Require d: d: Reserved 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 Allowed: The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI Request-URI.. 406 Not Acceptable: The 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 Authentication Re quired: The request requires user authentication. This response is issued by proxys 408 Request Timed Out: Couldn't find the user in time. 409 Conflict: 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 Reque st Entity Too Large 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 M edia 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 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 Interv al Too Small: Small: The 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.

http://tel ecompr otocol s.bl og spot.i n/

1/51

7/7/2014

The Tel ecom Pr otocol s 424 Bad Location Information : The request's location content was malformed or otherwise unsatisfactory. 428 Use Identity Header : Header : The server policy requires an Identity header, and one has not been provided. 429 Provide Provide Referrer Identity 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 Disallowed: The request has been rejected because it was anonymous. 436 Bad Identity-Info: 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. 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 Acceptable He re : 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 MIME body, which recipient can not decr ypt. 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. 5xx—Server Failure Responses 500 Server Internal Error : 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: 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 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. 6xx—Global Failure Failure Response s 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

20th March 2013

Add a comment

SIP Methods

SIP Servers: Proxy Servers:

- A stateless proxy proxy server server processes processes each SIP request or response based solely on the message contents. Once the message has been


2/51

7/7/2014

The Tel ecom Pr otocol s 424 Bad Location Information : The request's location content was malformed or otherwise unsatisfactory. 428 Use Identity Header : Header : The server policy requires an Identity header, and one has not been provided. 429 Provide Provide Referrer Identity 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 Disallowed: The request has been rejected because it was anonymous. 436 Bad Identity-Info: 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. 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 Acceptable He re : 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 MIME body, which recipient can not decr ypt. 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. 5xx—Server Failure Responses 500 Server Internal Error : 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: 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 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. 6xx—Global Failure Failure Response s 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

20th March 2013

Add a comment

SIP Methods

SIP Servers: Proxy Servers:

- A stateless proxy proxy server server processes processes each SIP request or response based solely on the message contents. Once the message has been


2/51

7/7/2014

The Tel ecom Pr otocol s parsed, proc essed, and f orwarded or r esponded to,no information information about the message is stor ed—no dialog dialog information information is is s tored. A stateless proxy never re-transmits a message, and does not use any SIP timers. - A stateful proxy server server keeps 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, reli relievi eving ng the user agent of this task. Al Also, so, a stateful proxy c an require user agent authentication. authentication.

Back-to-Back User Agents (B2BUA):

An B2B B2BUA UA is a type of SIP device that r eceives the SIP request, that reformulate reformulatess the request and s end it out as new r equest. 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 containing the media session information information as SDP. it also contains other information like like QoS and security information. 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 sess ion, a CANCEL CANCEL cannot be s ent becaus e the sess ion is is already established. A UA UAC C that originates an INVITE 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 retransmission 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 UPD ATE request request c an 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 An Expires unanswered INVITE request displayed displayed on a screen for the duration of specified in the Expires Expires header. Once a s ession is established, 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 limit on an established sess ion 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:regis sip:registrar.text.com trar.text.com SIP/2.0 Via: SIP/2.0/UDP 200.201.202.203:5060;branch= 200.201.202.203:5060;branch=z9hG4bK z9hG4bKus1812 us1812 Max-Forwards: Max-Forwar ds: 70 To: Marconi From: Marconi t.com> ;tag=3431 Call-ID: [email protected] CSeq: 1 REGISTER Contact: sip:marc sip:[email protected] [email protected] Content-Length:: 0 Content-Length -------------------------------------------------------SIP/2.0 200 OK Via: SIP/2.0/UDP 200.201.202.203:5060;branch= 200.201.202.203:5060;branch=z9hG4bK z9hG4bKus19 us19 To: Marconi [email protected]>;tag=8771 ;tag=8771 From: Marconi t.com> ;tag=3431 Call-ID: [email protected] CSeq: 1 REGISTER Contact:Marconi ; expires=3600 Content-Length:: 0 Content-Length -------------------------------------------------------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 ================================= --------------REGISTE --------------RE GISTER---------------------> R---------------------> <---------------200 OK 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:[email protected] SIP/2.0 Via: SIP/2.0/UDP 100.120.100.100:5060;branch=z9hG4bK3145r


3/51

7/7/2014

The Tel ecom Pr otocol s Max-Forwards:70 To: Marconi ;tag=63104 From: Te la ;tag=9341123 ;tag=9341123 Call-ID: [email protected] CSeq: 12 BYE Content-Length: 0

INVITE requests. F inal responses to all ot her 4.) ACK: The ACK method is used to acknowledge final responses to INVITE requests are never acknowledged. Final responses are defined as 2 xx xx,, 3xx, 3xx, 4xx, 4xx, 5xx, 5xx, or 6xx class responses. T he CSeq number is never incremented for an ACK, but the CSeq method is changed to ACK. T his is so that a UAS can match the CSeq number of th e ACK with the number of the corr esponding INVITE. INVITE. An ACK may contain an application/sdp message message body. This is permitted if the initial INVITE INVITE did not contain a SDP message body. If the INVITE 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; INVITE; a re-INVITE 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 natu re of ACKs to 2xx responses allows a message message body to be transported. A ho p-by-hop ACK reuses t he same branch ID as the INVITE 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:[email protected] sip:[email protected] SIP/2.0 Via: SIP/2.0/TCP 100.200.102.100:5060;branch=z9hG4bK1234 Max-Forwards:70 To: M arconi ;tag=902332 ;tag=902332 From: Tesla ;tag=887823 Call-ID: [email protected] CSeq: 3 ACK Content-Type: application/sdp Content-Length: 100 (SDP not shown)

5.) CANCEL: The CANCEL: The CANCEL method is used to ter minate 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 pro xies and user agents can match the CSeq of the CANCEL with with the CSeq of the pending INVITE INVITE to which it corresponds. T he branch ID for a CANCEL matches the INVITE INVITE that it is canceling.

CANCEL sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP 100.100.122.122:5060;branch=z9hG4bK3134324 Max-Forwards:70 To: Marconi From: Tesla ;tag=034324 Call-ID: [email protected] CSeq: 1 CANCEL Content-Length: 0 6.) O PTIONS: 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@tex sip:[email protected] t.com SIP/2.0 Via: SIP/2.0/UDP 100.200.100.100 ;branch=z9hG4bK1834 Max-Forwards:70 To: Marconi From: T esla ;tag=34 Call-ID: [email protected] CSeq: 1 OPTIONS Content-Length: 0

7.) REFER: The REFER: The REFER method is used by a user agent to reque st 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, URI, the REFER is pr obably being used to implem implement ent a call transfer service. REFER can also used to implement peer-to-peer call control.

REFER sip:[email protected] SIP/2.0 Via SIP/2.0/UDP test.com:5060;branch=z9hG4bK9323249 Max-Forwards: 69 To: ;tag=324234 From: Tesla ;tag=44432 Call-ID: 3419fak32343243s1A9dkl


4/51

7/7/2014

The Tel ecom Pr otocol s CSeq: 5412 REFER Refer-To: Content-Length: 0 8.) SUBSCRIBE: The SUBSCRIBE SUBSCRIBE method is used by a user agent to establish a subscription for the p urpose 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 SUB SUBSCRIB SCRIBE E within the dialog before the expiration time. A server accepting a subscription returns a 200 OK response also obtaining an Expires Expi res head er field. There is no “UN “UNSUB SUBSCRIBE SCRIBE”” method used in SIP—i SIP—instead nstead a SUB SUBSCRIB SCRIBE E 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 ter minated. UA Proxy-Server Proxy-Serv er Presence Agent ==================================== ------------Subscribe-----------> -----------Subscribe--------------> <-----202 Acce Accepted--------------pted--------------<-----------------202 Accep Accepted--ted--<------------------------------------NOTIFY----------------------------------------------------200 OK---------------------------------------------> ----------------------------Subscribe--------------------------------------> <-----------------------------------200 OK-------------------------------

SUBSCRIBE sip:[email protected] SIP/2.0 Via SIP/2.0/UDP 200:200:200:201:5060;branch=z9hG4bKABDA ;received=192.0.3.4 Max-Forwards: 69 To: From: Te sla ;tag=1814 ;tag=1814 Call-ID: 452k59252058234924lk34 CSeq: 3412 SUBSCRIBE Allow-Events: Allow -Events: dialog Contact: 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 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 NOTIFY requests contain an Event head er field indicating the package and a Subscription-State hea der field indicating the current state of the subscription. The Event header field will contain the package name used in the subscription. A NOTIFY 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

10th January 2013

Add a comment

Type of BICC calls

BICC Bearer establishment procedures: 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 th e forward direction, i.e. the IPB IPBCP CP request is sent fr om 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. message.

-

-

APM (Connected) exchange :


5/51

7/7/2014

The Telecom Protocols 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

3rd December 2012

Add a comment

Core Network Architecture - Interfaces

The interfaces and protocols supported towards the networks are mentioned below:

[http://4.bp.blogspot.com/-J59OmJgtxwM/ULxV9a5i0aI/AAAAAAA ABPg/1DYT1mqCKWs/s1600/interfaces.JPG] Networ k Interf aces and Protocols

Posted 3rd December 2012 by Pramod Labels: Codec Management 0

23rd October 2012

Add a comment

Codec Management

Codec Management Objectives 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: 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

http://telecomprotocols.blogspot.in/

6/51

7/7/2014

The Telecom Protocols recommended. Standard s Intrinsi c 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/AAAAAA AAAKE/ MrBbw85JEuY/s1600/codec1.JPG]

Bandwidth efficiency: 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 f ollowing techniques : silence suppression, AAL2/RTP multiplexing, IP header compression.

Transcoder Resource s optimization:

The third goal of the codec management is to optimize the transcoder resources in the MGW. So, TrFO must be used whenever possible.

Optimization of delay: 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 Labels: Codec Management 0

19th October 2012

Add a comment

TFO - Tandem Free Operation

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


7/51

7/7/2014

The Telecom Protocols 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 Labels: Codec Management 0

17th October 2012

Add a comment

TrFO - Transcoder Free Operation

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

Posted 17th October 2012 by Pramod Kumar Labels: Codec Management 5


View comments

8/51

7/7/2014

The Telecom Protocols

11th October 2012

ISUP Release Cause Values

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

Subsc riber absent

15

Call rejected

16

Number changed

17

Redirection to new destinat ion

18

Call rejected because of a feature at the destinat ion

19

Exc hange routing error

1A

Non select ed user clearing

1B

Destinat ion out of Order

1C

Invalid number format (address incomplet e)

1D

Facility rejected

1E

Response to Status Enquiry

1F

Normal, unspecified

22

No circ uit/c hannel available

26

Network out of order

29

Temporary failure

39

Bearer capabilit y not authorized

51

Invalid call reference value

52

Identified channel does not exis t

54

Call identity in use

57

User not member of Closed User Group

58

Incompatible destinat ion

5F

Invalid mess age, unspecified

60

Mandatory information element is miss ing

6F

Protoc ol error, unspecified

7F

Interworking, unspecified

Posted 11th October 2012 by Pramod Kumar Labels: SS7 Protocol Stack 0

11th October 2012

Add a comment

Supplementary Service Codes

Serv ice Name HEX BINARY ================================================== CLIP CLIR COLP COLR All Call Forward CFU All Conditional call forward CFB CFNRY CFNRc CD ECT CW CH CCBs-A CCBs-B MPTY AOCI (information) AOCC (Charging) All call Barring Outgoing call Barring


11 12 13 14 20 21 28 29 2A 2B 24 31 41 42 43 44 51 71 72 90 91

00010001 00010010 00010011 00010100 00100000 00100001 00101000 00101001 00101010 00101011 00100100 00110001 01000001 01000010 01000011 01000011 01010001 01110001 01110010 10010000 10010001

9/51

7/7/2014

The Telecom Protocols baoc boic boicExHC Barring of Incoming calls baic bicRoam

92 93 94 99 9A 9B

10010010 10010011 10010100 10011001 10011010 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.

Posted 11th October 2012 by Pramod Kumar Labels: GSM 0

Add a comment

3G Call Flow

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 -->| |--> |<-|--> |<-|--> |<-|--> |<-|--> |<-|--> |<-|<------------Dir_Trnx(CALL_ALERT)

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_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)-------------------->


10/51

7/7/2014

The Telecom Protocols |--> IuReleaseCmd ------ ------ ------- ------ -|<-- IuReleaseComp ----- ------ ------ ------ ----------Dir_Trnx(CALL_RELCOMP) <--| ------------------IuReleaseCmd <--| ------------------IuReleaseComp -->| ************************************************************************************************* Posted 9th October 2012 by Pramod Kumar Labels: Call Flows 0

Add a comment

Location Update Message Decoding

6th October 2012

Location Update Flow : *********************************************************************** 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 -->| ***********************************************************************

CM Service Request/Location Update Request *******************************************************************

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 21 57 05 08 00 13 f0 79 00 01 00 01

Message discriminator length message type BSSMAP 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 05

08 70 13 f0 79 ff fe 30 08 89 88 88 12 45 12 00 00 21 01 00

message type and length of layer3 TI flag, value and protocol discriminator (Mobility management).

message type of LU Chiperkey sequence No. Location Area Identification IMSI Mobility Management.

Authentication Request ********************************************

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

11/51

7/7/2014

The Telecom Protocols 00

13 05 12 01/02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Ctrl Channel not further specified (00), spare (000), sapi (000)

Length (19) Mobility Management Message Type DTAP Possible value for ciphering key sequence number Authentication RAND

Authentication Response **********************************************

01 00 06 05 54 00 00 00 00 01 00 06 05 54 00 00 00 00

Message Discriminator Ctrl Channel not further specified (00), spare (000), sapi (000) Length (06) Mobility Management Message Type Authentication SRES

Class Mark Request ************************************************* 00 01 58 00 01 58

Message Discriminator Length (1) Message Type

Class Mark Update ***********************************

00 0b 54 12 03 30 59 81 13 02 60 14 00 00 0b 54 12 03 30 59 81 13 02 60 14 00

Message Discriminator Length (10) Message Type Classmark Information Type 2 Length (03) Class Mark Classmark Information Type 3 Length (02) Class Mark end of Optional parameters.

Cipher Mode Command ********************************************

00 0e 53 0a 09 07 00 00 00 00 00 00 00 00 23 01 00 0e 53 0a 09 07 00 00 00 00 00 00 00 00 23 01

Message Discriminator Length (15) Message Type Encryption Information Length (09) Encryption Information Cipher Response Mode (Phase 2) Spare/ IMEISV must be Included By The Mobile Station

Cipher Mode Complete 00 10 55 20 0b 17 09 33 05 70 87 70 35 17 01 f9 2c 01 00 10 55 20


Message Discriminator Length (17) Message Type Layer 3 Message contents (Phase 2)

12/51

7/7/2014

The Telecom Protocols 0b 17 09 33 05 70 87 70 35 17 01 f9 2c 01

Length (11) Contents Chosen Encryption Algorithm No Encryption used

Location Update Accept ********************************************

01 00 0e 05 02 13 f0 69 00 03 17 05 f4 0f 2f 20 04 00 02 01 01 00 0e 05 02 13 F0 69 00 03 17 05 f4 0f 2f 20 04 00 02 01

Message Discriminator Ctrl Channel not further specified (00), spare (000), sapi (000) Length (15) Mobility Management Message Type MCC1-> 3, MCC2 ->1, MCC3-> 0 MCC: 310 MNC1->9, MNC2->6 MNC: 96 LAC Mobility Identity Parameter Length ST 0/Even Number of Address Signals / TMSI Identity Digits

Clear Command ******************************

00 04 20 04 01 09 00 04 20 04 01 09

Message Discriminator Length (04) Message Type Cause Length Extension bit (last octet) / Call Contro l Normal Event

Clear Complete *****************************

00 01 21 00 01 21

Message Discriminator Length (1) Message Type

Posted 6th October 2012 by Pramod Kumar Labels: Call Flows 2

View comments

SCCP Messages

27th September 2012

The Signalling Conne ction 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 0—Basic 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 1—In-sequence delivery connectionless class - it adds the sequence control to class 0 service by requiring to insert the same SLS to all NSDU.

• Class 2—Basic 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.


13/51

7/7/2014


[http://1.bp.blogspot.com/-

L7w1xQzk7wQ/UGP2Fhb-vLI/AAAAAAAA AI4/rBUclMCwTRI/s1600/scc p.JPG]

• Class 3—Flow 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 connectionoriented 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 Acknowledge ment (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. Release d (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


14/51

7/7/2014

The Telecom Protocols 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. U nitData (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 t o 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 Conge sted (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-ofservice, 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 Subsystem‑Out‑of ‑Service‑Request message, to the requesting SCCP if both the requested SCCP and the backup of the affected subsystem agree to the reque st. It is used for SCCP subsystem management. Posted 27th September 2012 by Pramod Kumar Labels: SS7 Protocol Stack 0

11th September 2012

Add a comment

LTE - Long Term Evolution

[http://4.bp.blogspot.com/rS3es3A3NQI/UEmDWcT8ipI/AAAAAAAAAH8/y2eJXo7pHAI/s1600/3gpp.JPG]

Why LTE? The first qu estion 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:


15/51

7/7/2014

The Telecom Protocols Improve QoS by de creasing 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 tr affic on CS (Circuit Switched) Network and Data service on packet net wok - 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/AAAAAAA AAHU/gUrMhig9kJ0/s1600/lte_archi.JPG]

Entity Summery: MME (Mobile Management Entity) : MME provides mobility and session contr ol management. SGW (Serving Gate way): Routes and forwards the user data packets. PGW (PDN Gateway): Provides UE session connectivity to external packet d ata network (PDN). PCRF : Supports service d ata flow detection, policy enforcement, and flow based charging. eNodeB: Receive and sends radio signals to and from the antennas. Schedules uplink and downlink data the UE. Provides Ethernet links to the EPC elements and o ther eNodeB.

to/from

LTE eUTRAN architecture ele ments: 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/AAA AAAAA AHo/AR9UNRVc1uA/s1600/lte_mimo.JPG]

LTE M odulation Techniques: OFDMA (Orthogonal Frequency Division Multiple acce ss): 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 require s more power at transmission.

SC-FDMA (Single-Carrier Freque ncy 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 r equire less power. It is used UL to convey UE battery. MM E Functionality: Communicates with the HSS for the user au thentication and subscriber profile downloads.


16/51

7/7/2014

The Telecom Protocols Communicates with the eNodeB and SGW for th e session control and bearer setup. MM E Interfaces:

S10: To othe r 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/AAAA AAAAAIM/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 r ecords to external billing systems) Serves as the cross-techno logy mobility anchor (Support mobility between 3GPP/non-3GPP access to Non3GPP/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 contr ol 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). Posted 11th September 2012 by Pramod Kumar Labels: 4G, LTE 0


Add a comment

17/51

7/7/2014


MNP Call Flows

10th September 2012

For call related message, there are two type of solutions defined for portability Domain: A. Mobile Number Portability-Signaling Relay Function (M NP- 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 f rom NPDB. A. Mobile Number Portability-Signaling Relay Function (M NP- SRF) Scenarios:

[http://1.bp.blogspot.com/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/AAAAAAAAA DQ/pU7N7iI4zIY/s1600/non-ported.JPG]


18/51

7/7/2014

The Telecom Protocols 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 r eplaces 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:

[http://4.bp.blogspot.com/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 network’s GMSCa. 3. When GMSCa receives the ISUP IAM, it requests routing infor mation 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.

Call A.3: Mobile Originated Call to a Ported or not known to be P orted Number – Originating Network=Subscription Network – Direct Routing

[http:/ /3.bp.blogspot.com/-Ulcgcb-


19/51

7/7/2014

The Telecom Protocols y8Ps/UESOg7RSy6I/AAAAAAAAADo/mcYnuAk3Dps/s1600/ported-out.JPG] Fig3: Mobile Originated Call to a Ported or not know n to be Ported Number – Direc t Routing

1. MSA ori ginates a call to MSISDN. 2. VMSCA routes the call to the network’s 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 ad ded i n the IAM or not.

Call 4: Call to a Ported Number – Indirect Routing

[http://3.bp.blogspot.com/-ayYVUEYKKm4/UESQAgNdoI/AAAAAAAAA Dw/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 Refere nce to Subscription Network

[http://3.bp.blogspot.com/-FtDddkt5tlY/UESUN3vxI2I/AAAAAAAAA EI/k_FEH4LO-rM/s1600/portedout_indirectrouting.JPG] Fig5: Call to a Ported Number Indirect Routeing with Reference to Subsc ription Network


20/51

7/7/2014

The Telecom Protocols 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 T T on SCCP may be set to SRI. 3. When MNP_SRF/MATF receives the message, MNP_SRF/MATF operat ion 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 r elays 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 infor mation by submitting a MAP SRI to MNP_SRF/MATF. T he TT on SCCP may be set to SRI. 7. When MNP_SRF/MATF receives the message, MNP_SRF/MATF operat ion is triggered. The MNP_SRF/MATF functionality analyses the MSISDN in the CdPA and identifies th e 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, th e 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/AAAAAAAAA EY/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 r outeing 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. 6. GMSCB uses the MSRN to route the call to VMSCB. Call B.2: TQoD Number is not ported


21/51

7/7/2014


[http://4.bp.blogspot.com/-bh3pnZ6qySI/UESlPOKup8I/AAAAA AAAAE o/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 an alysis 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 r esponds back to the GMSCB to continue the normal call setup procedure for MT calls. 4. The GMSCB requests rou teing 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. 6. The MSC/VLRB returns an MSRN back to the HLRB. 7. The HLRB responds to the GMSCB by sending an SRI ack with an MSRN. 8. GMSCB uses the MSRN to route the call to VMSCB.

Call B.3: TQoD Number is ported

[http://2.bp.blogspot.com/-grscysZP02M/UESl5CPCI-I/AAAAAAA AAEw/-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 respo nds 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 Ro uteing Number carried in ISUP IAM message; also the MSISDN is included in IAM. 5. The GMSCB requests rou teing information by submitting a MAP SRI to the HLRB, including the MSISDN in the request. The capability to route messages to the correct HLR is required.


22/51

7/7/2014

The Telecom Protocols 6. 7. 8. 9.

The HLRB requests an MSRN from the MSC/VLRB where the mobile subscriber currently is registered. The MSC/VLRB returns an MSRN back to the HLRB. The HLRB responds to the GMSCB by sending an SRI ack with an MSRN. GMSCB uses the MSRN to route the call to VMSCB.

Call B.4: QoHR Number is ported

[http://2.bp.blogspot.com/-plVAprSq4LE/UESm2iHYwVI/AAAAAAAA AE4/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 quer y to the NPDB, including the MSISDN in the query. 5. The NPDB detects that the MSISDN is ported and r esponds back to the G MSCA with a Routeing Number pointing out the Subscription network. 6. 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. 7. The GMSCB requests routeing information by submitting a MAP SRI to the HLRB, including the MSISDN in the request. The capability to route messages to the correct HLR is required. 8. The HLRB requests an MSRN from the MSC/VLRB where the mobile subscriber currently is registered. 9. The MSC/VLRB returns an MSRN back to the HLRB. 10. The HLRB responds to the GMSCB by sending an SRI ack with an MSRN. 11. GMSCB uses the MSRN to route the call to VMSCB.

Call B.5: OQoD Number is not ported


23/51

7/7/2014

The Telecom Protocols [http://3.bp.blogspot.com/-bP5zgf-YFE8/UESnttyMlrI/AAAAAAA AAFA/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 an d 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. 5. The GMSCB requests routeing information by submitting a MAP SRI to the HLRB, including the MSISDN in the request. 6. The HLRB requests an MSRN from the MSC/VLRB where the mobile subscriber currently is registered. 7. The MSC/VLRB returns an MSRN back to the HLRB. 8. The HLRB responds to the GMSCB by sending an SRI ack with an MSRN. 9. GMSCB uses the MSRN to route the call to VMSCB.

Call B.6: OQoD- Number is porte d

[http://3.bp.blogspot.com/-GzIWOpIYcxY/ UESoqbnEO8I/AAAAAAA AAFI/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 b ack to the VMSCA 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. 5. The GMSCB requests routeing information by submitting a MAP SRI to the HLRB, including the MSISDN in the request. The capability to route messages to the correct HLR is required. 6. The HLRB requests an MSRN from the MSC/VLRB where the mobile subscriber currently is registered. 7. The MSC/VLRB returns an MSRN back to the HLRB. 8. The HLRB responds to the GMSCB by sending an SRI ack with an MSRN. 9. GMSCB uses the MSRN to route the call to VMSCB.

Posted 10th September 2012 by Pramod Kumar Labels: MNP, Mobile Number Portability 0

9th September 2012

http://telecomprotocols.blogspot .in/

Add a comment

H.248/MEGACO Protocol

24/51

7/7/2014

The Telecom Protocols H.248 is protocol used be tween 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 pr ocessing. - 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 [sende rIPAddress]: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 ( transact ionID { conte xt ID {{{{}}}}) where Transaction ID = 1 to 4294967295 (a 32bit value) Context ID= null to 65535 ( 16bit value) Rep ly ( 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 Reque st 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 fr om 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 t o 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 conte xt. The context is deleted when the last termination is subtracted fro m a termination. Command: Command are used to manipulate th e 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]}

25/51

7/7/2014

The Telecom Protocols 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] [,PackagesD escriptor]} - Audit-Capability: Audit Capability commands returns the all possible propr ties, events, signals and statistics of the Termination. - Notify: The Notify command allows the MG to inform the MGC of the occurr ence of events in t he 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 (Ter minationIDs), 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. Ther e 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 par ameters. - 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.


26/51

7/7/2014

The Telecom Protocols - 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: r eturns the list of package realized by the termination and it is used with the AuditValue command. - ObservedEvent Descriptor s: 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 (r oot): Defines the generic proper ties 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 anno uncement functionality at a MG. Announcement will be played endlessly by the MG, until the MGC stops t he announcement. - Media gateway resource congestion hand ling (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

8th September 2012

Add a comment

Mobile Number Portability (MNP)

Mobile Number Portability (MNP): Mobile Number Portability (MNP) is the ability for a UMTS or GSM mobile subscriber to change th e subscription network within a portability d omain while retaining her original MSISDN.


27/51

7/7/2014


[http://3.bp.blogspot.com/veVG8GphPhQ/UER4tAYyW1I/AAAAAAAAACw/Fu9cOkFxiVo/s1600/port1.JPG] Fig 1: General Architecture of Portabili ty for Calls

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. T his may or may not be the Number range holder net work. For example if a subscriber is ported-out from Vodafone to Airtel, then Vodafon e network if called as Donor network. If this number range belongs to Vodafo ne then it also called NRHN so in this NRHN and Donor ne twork 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 a s only Donor network and Idea would be NRHN. Number Portability Database (NPDB): A Database which provides port ability 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 po rted 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 porta bility 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 th e portability domain, in a PLMN supports the direct routing, this IAM (7) directly routed to the subscription network. - Indirect Routing : Indirect Routeing o f 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 subscriber’s subscription network. For example In Fig 1, If a message(2) originated inside the portability domain, in a PLMN support indirect ro uting routes this IAM(2) to Number Range holder network. The Number range holder network route the calls to subscription network. - If a call or iginated outside th e 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 r ange holder network is identical with the donor network (Example if number is of Airtel an d 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 r ange 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)

28/51

7/7/2014

The Telecom Protocols ================================================================================ 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

Posted 8th September 2012 by Pramod Labels: MNP, Mobile Number Portability 0

Add a comment

Session Initiation Protocol (SIP)

7th September 2012

Session Initiation Protocol (SIP) SIP stack handled over the following layer and data t ransfer based o n 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 interne t 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 T CP cleint sends SYN (synchronization) message to open the connection, which (SYN) contains initial sequence number, the client will use during the conne ction. 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 DAT A 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 th e timer,and if it expires, sender resend the segment.FIN message use to close the T CP connection. Window size is use represen ting the initial maximum number of unacknowledged segments is sent.


TCP-Client TCP-Serve r ------------------------SYN(SN_client)-----------------------> <------- ------ -SYN/AK(SN_server, SN_client)----- ------ -----

29/51

7/7/2014


----------------------------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 pr otocol develop by IETF to setup, modify, and tear d own multimedia session such as Internet telephony calls over IP. DNS ( Domain Name Se rvice ): - 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 ar e 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 INVITE 100 Trying

ACK

UACb --------------------------------------> -------------------------------------> <----------------------------------- 180 Ringing <----------------------------------- 200 OK ------- ------ ------ ------- ------ ---->

<------- ------Media Session Established------- ------- -> <------------------------------------ BYE -------------------------------------> 200 OK INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP lab.high-voltage.org:5060;br anch=z9hG4bKfw19b Max-Forwards: 7 0


30/51

7/7/2014

The Telecom Protocols To: G. Marconi From: Nikola Tesla ;tag=76341 Call-ID: [email protected] CSeq: 1 INVITE Subject: About That Power Outage... Contact: Content-Type: application/sdp Content-Length: 158 v=0 o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org s=Phone Call c=IN IP4 100.1 01.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 proto col. Description of header information: - Via contains the add ress at which sender is expecting to receive responses to this request. usua lly written as a host name that can be resolved into an IP address using a DNS query. It also contains a branch parameter that iden tifies 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 trad itional 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 d irect 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;br anch=z9hG4bKfw19b; received=100.101.102.103 To: G. Marconi t;;tag=a53e42 From: Nikola Tesla ;tag=76341 Call-ID:[email protected] CSeq: 1 INVITE Contact: 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 F rom header field are not reversed b ut 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 ;tag=a53e42 From: Nikola Tesla ;tag=76341 Call-ID:[email protected] CSeq: 1 INVITE Contact: Content-Type: application/sdp Content-Length: 155 v=0 o=Marconi 2890844528 2 890844528 IN IP4 tower.radio.org s=Phone Call c=IN IP4 200.2 01.202.203 t=0 0 m=audio 60000 RTP/AVP 0 a=rtpmap:0 PCMU/8000


31/51

7/7/2014

The Telecom Protocols ACK sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP lab.high-voltage.org: 5060;branch=z9hG4bK321g Max-Forwards: 7 0 To: G. Marconi ;tag=a53e42 From: Nikola Tesla ;tag=76341 Call-ID: <[email protected] 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 tr ansaction.This message exchange shows the SIP as an end-to-end signaling proto col.

a BYE request is sent by Marconi to terminate the media session: BYE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP tower.radio.org:5060;branch=z9hG4bK392kf Max-Forwards: 7 0 To: Nikola Tesla ;tag=76341 From: G. Marconi ;tag=a53e42 Call-ID: [email protected] CSeq: 1 BYE Content-Length: 0 The Via header field in this example is populated with Marconi’s host address and contains a ne w transaction identifier since the BYE is considered a separ ate transaction fr om the INVITE or ACK transactions shown previously. The T o 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;br anch=z9hG4bK392kf;received=200.201.202.203 To: Nikola Tesla ;tag=76341 From: G. Marconi ;tag=a53e42 Call-ID: [email protected] 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. T his 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 o f 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 Serve r 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 REF ER, SUBSCRIBE, NOTIFY, MESSAGE, UPDATE, INFO, and PRACK methods are described in separ ate 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


32/51

7/7/2014

The Telecom Protocols to cancel the session—a CANCEL cannot be sent because the session is already established. A media session is considered established when the INVITE, 200 O K, 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 u sed 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. T his 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. T he ACK may not be used to modify a media description that has alr eady been sent in the initial INVITE; a re-INVITE must be used for this purpo se. - 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: T he INFO method is used by a user age nt to send call signaling infor mation to another user agent with which it has an established media session. T his is different from a r e-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 ;tag=12323 From: Newton ;tag=981 Call-ID: [email protected] RSeq: 314 CSeq: 1 INVITE Content-Length: 0 PRACK sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP lucasian.trinity.cambridge.edu.uk;branch=z9hG4bKdtyw Max-Forwards: 7 0 To: Descartes ;tag=12323 From: Newton ;tag=981 Call-ID: [email protected] 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 To: Descartes ;tag=12323 From: Newton ;tag=981 Call-ID: [email protected] 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 endpoint. - 182 Call Queued : This respon se is used to indicate tha t the INVITE has been received, and will be processed in a queue.


33/51

7/7/2014

The Telecom Protocols - 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 fo r 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.

Posted 7th September 2012 by Pramod Labels: SIP, VOIP (Voice over IP) 0

6th September 2012

Add a comment

MTP 3 User Adaptation (M3UA) - SIGTRAN Stack

M3UA is a protocol for supporting th e transport o f any SS7 MTP3-User signaling (e.g., ISUP and SCCP messages) over IP using the services of the Stream Control Tran smission 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 p hysical 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—–

Posted 6th September 2012 by Pramod


34/51

7/7/2014

The Telecom Protocols Labels: SIGTRAN Stack - M3UA 3

View comments

Stream Control Transmission Protocol (SCTP)

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 c onsideration using the verification tag and cookies. - It is message oriented protocol. SCTP Association initial ization EndPoint-A clos ed stat e

EndPoint-B

———INIT(veri tag, init tag, IP)————–> Cloesed Stat e

cooki e wait stat e

<—–INIT ACK(init tag,IP, verificati on tag)—-

cooki e 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/initA ck, ABORT is sent. Handle Stream: Endpoints sends (in init and initACK) the number of outbound stream (OS), and maximum inbound stream. if peer’s 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 Wi ndow (cwnd): An SCTP variable that limits t he 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 recent ly cal culated receiver window of its peer, in number of bytes . This gives the sender an indicat ion of the space available in the receiver’s inbound buffer . SCTP association: A protocol relationship between SCTP endpoints, composed of the two SCTP endpoints and protocol state information including Verificati on Tags and the currently act ive set of Transmis sion Sequence Numbers (TSNs), etc . An assoc iation can be uniquely identified by the transport addresses used by the endpoints in the associati on. 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 packet s can be received. All transport addresses us ed 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 attac hed to each user message. Transmission Sequence Number (TSN): A 32-bit sequence number used internally by S CTP. One TSN is att ached to each chunk containing user data to permit the receiving SCTP endpoint to ack nowledge its receipt and detect duplicate deliveries. Transport Addre ss: In the case of SCTP running over IP, a transport address i s defined by the combinati on 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|V erificati on Tag| Destinat ion Port Address| Source Port Address| – Source Port Number (16bit, Sender Port Number) – Destinati on Port Number (16bit, Receiver Port – Verificat ion Tag (32bit, to validate the sender, it should same as initiat e tag received in INIT during the starti ng the associat ion. 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…)


35/51

7/7/2014

The Telecom Protocols - 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 Fea tures:

- Transport Layer Protocol - Alternative to TCP and UDP. - Uni-cast Protocol - Communication between the 2 end points. - Se ssion 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/AAAAAAAA AGI/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 ga p in TSN.

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

Posted 4th September 2012 by Pramod Labels: SIGTRAN 0

4th September 2012

Add a comment

SIGTRAN

SIGTRAN (Signalling Transport) is a set of protocols defined to transport SS7 messages over IP networks.


36/51

7/7/2014


[http://1.bp.blogspot.com/GjPvWnulWwE/UEWk th1UhUI/AAAAAAA AAGo/T3fLdFrEXbQ/s1600/sig.JPG]

SIGTRAN allows IP networks to inter -worked with the Public switched Telephone Network (PSTN) a nd vice-versa. [http://3.bp.blogspot.com/-ZOEmaQpWYMQ/UEWTnRouBXI/AAAAAAA AAFY/JiRUDCBNrUs/s1600/sigtran.JPG]

The Sigrtan protocol stack based on following components:

[http://4.bp.blogspot.com/-m3veyev1Ros/UEWUzlJSPPI/AAAAAA AAAFg/jHkKW 7zb-u8/s1600/sigtran-component.JPG]

- A Standard IP stack. - A common signalling transport protocol, that we called as SCTP (stream transmission Protocol) - Adaptation Layer: T hese are the Adaptation layers for MTP2, MTP3 and ISUP, called M2PA, M2UA, M3UA, and SUA.

SIGTRAN Stack:

[http://3.bp.blogspot.com/-5ONMD2JDl3k/UEWXicXCeXI/AAAAAAA AAF4/cH8X7eKxaUM/s1600/sigtran_stack.JPG]

Posted 4th September 2012 by Pramod Kumar Labels: SIGTRAN 0

3rd September 2012

Add a comment

Intelligent Networks (IN) and CAMEL

Intellige nt Networks (IN):-

Intelligent Networks is a concept service intelligence resides i n a central node called an SCP and SS Ps (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 & Vend or Independent Implementation - MSC just focuses on core job of call processing

Network Before IN: Before IN application, there was messed network for every node:


37/51

7/7/2014


[http://3.bp.blogspot.com/JhjEnqT-8Vo/UEXP_08WKfI/AAAAAAAAAHA/ngDfIt1n4m0/s1600/cap.JPG]

[http://4.bp.blogspot.com/-vGKnLdSBIg/UERY1QTItII/AAAA AAAAAB o/0W9Y2WqBfNI/s1600/preIN.JPG]

Network with IN: After IN implementation, Network is organised.

[http://4.bp.blogspot.com/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). Ther e are two types of DPs: T DP and EDP. EDP is


38/51

7/7/2014

The Telecom Protocols also of two Type. -Trigger Dete ction Point (TDP): statically armed DP at which the MSC/SSP first contacts the SCP to request fo r 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 po int 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 d elivers additional special resources into the call, for example play voice announcements or collect DTMF tones from the user. Customized Applications for M obile ne tworks Enhanced Logic, or CAMEL for 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. T he 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 Ope rator 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 inte rrogated 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/-NyDyca_hRU/UERZ7e9 wIBI/AAAAAAAAAB4/s8db mdPm VOc/s160 0/dp2.jp g] DP2 (OCSI)

Service Screened in first SIOC: COS, ODB (BAOC & BAOC roaming outside the HPLMN Country), BAOC, CUG, IN (O-CSI)


39/51

7/7/2014

The Telecom Protocols 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 ————————–>

[http://1.bp.blogspot.com/pnD7 BUHrEAs/UERahs yuBwI/AAAAAAAAACA/q1SGjqC8B2c/s16 00/dp1 2.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———————>

[http://2.bp.blogspot.com/YMPkS7WSFZA/UERas9SAAbI/AAAAAAAAACI/xjcGACgZ51w/s1600/dp2_CF.jpg]


40/51

7/7/2014


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

MSC-A

HLR

SCP

PSTN

================================================================== ————IAM———>

————SRI—————–> <-SRI ACK(CFU,TCSI & OCSI)–

———————-INITDP(12)———–>

<—————–CONTINUE—————-

————————INITDP(2)———–>

<——————CONNECT—————-

—————————-IAM————————–>

Applying O-CSI to a call forwa rded 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. A-Party

MSC-A

HLR

SCP

PSTN

=================================================================== ————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(E DP, 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(E DP, 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———— <———————-P RI 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.colleague’s ext ension), 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).


41/51

7/7/2014

The Telecom Protocols 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 subscriber’s 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-B asic Service Code Callforwarding SS Pending MSC Address time and timezone

carrier service key (m) highLayer capabilit y (HLC) eventty pe 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 t o cancel all EDPs and report.


42/51

7/7/2014

The Telecom Protocols - 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 gsmSS F to continue the basic c all 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. - Assis ting 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:


43/51

7/7/2014


[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

3rd September 2012

Add a comment

MAP (Mobile Application Part)

MAP (Mobile Application Part):

[http://3.bp.blogspot.com/UaLxssk5-kA/UESDKLQSYhI/AAAAAAAAADA/Ly_yINrXmWU/s1600/map.JPG]

MAP is the protocol is to used to allow the GSM network nodes within the NSS to communicate with the each oth er to provide the service, such as roaming, SMS, Subscriber authentication. MAP is transported a nd encapsulated with the SS7 protocols MTP, SCCP, and TCAP. MAP Phase 2 operations can be d ivided into the following main categories: • Mobility Management • Operation and Maintenance • Call Handling • Supplementary Services • Short Message Service


44/51

7/7/2014

The Telecom Protocols 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 subscriber’s 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 infor mation, it can retrieve the infor mation 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 opera tions: • 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 - Fo llowing 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 r esources • processAccessSignalling • forwardAccessSignalling • prepareSubsequentHandover - If another inter-MSC is required (back to MSC-A or to another MSC, C), then MSCB sends this message to MSC-A. It contains the information required for MSC-A to send a p repareHandover 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 t o 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 upd ate a VLR with specific subscriber data when the subscriber’s profile is modified. A subscriber’s profile can be modified, because the operator has changed the subscription of the subscriber’s 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. - restore Data: When a VLR r eceives 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 b ecause of an HLR outage, th e VLR sends a restoreData message to th e HLR to synchronize the data. Call Handling: Call handling does not h ave subcategories of o perations; it simply has the following two operations: • sendRoutingInfo - The GMSC then identifies the subscriber’s HLR based on the MSISDN, and invokes the MAP operation sendRout ingInformation with the MSISDN as a parameter towards the HLR to find out where the MS is presently located. • provideRoamingNumber - Because of past location update s, the HLR already knows the VLR that curr ently 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. T he VLR assigns an MSRN from a pool of available numbers and sends th e 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;


45/51

7/7/2014

The Telecom Protocols • 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 curr ent password or modify or activate a supplementary service. Unstructured Supplementary Service s (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 tu rnaround 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 Labels: SS7 Protocol Stack 0

2nd September 2012

Add a comment

ISUP (ISDN User Part)

[http://2.bp.blogspot.com/TOkLnJpAI6Q/UEHRJMz4n2I/AAAA AAAABP A/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 en d, 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 t he message element of IAM, ACM, ANM, REL, RLC, COT... Answers: 1.) ISUP allows the call control signaling to be separ ated from the circuit that carries the voice stream over interoffice trunks. ISUP call scenario: A-Party B-Party IAM---------------------------------> COT---------------------------------> <------------------------------------ACM <------------------------------------ANM REL----------------------------------> <------------------------------------RLC


46/51

7/7/2014

The Telecom Protocols 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 th e CIC identifies a bearer circuit b etween 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 Te st: Continuity testing verifies the physical bearer facility between two SSPs. When CAS signaling is used, a call setup fails if th e voice path is faulty. Using ISUP signaling, it is possible to set up a call using the signaling network without knowing that the bear er 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 Labels: SS7 Protocol Stack 0

2nd September 2012

Add a comment

TCAP (Transaction Capabilities Application Part)

Questionnaire on TCAP:

[http://1.bp.blogspot.com/mSZsK87KaHo/UEHQvj37ciI/AAAAAAAABO4/3AcTv8ouRuI/s1600/tcap.JPG]

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.


47/51

7/7/2014

The Telecom Protocols 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: OT ID, DTID)): continues a transaction , giving the permission to receiving node to end the transaction - Conversation without permission( TIDpresent: OT ID, 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 Pro tocol 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 operation’s 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 con text for a transaction. Information, such as the protocol version and application context, is used to ensure that two nodes interpret the component sublayer’s 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 Conte xt Name and, optionally, Protocol Version and User Information. It is used to r equest dialogue information fro m 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 Erro rs are anomalies within the application procedur e.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 fr om the normal actions by


48/51

7/7/2014

The Telecom Protocols the user. The user might take an action, such as abandoning the call prematurely. Posted 2nd September 2012 by Pramod Labels: SS7 Protocol Stack 0

1st September 2012

Add a comment

SCCP (Signalling Connection Control Part)

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.

[http://1.bp.blogspot.com/-pZd3barj4I/UEHO6nSJ95I/AAAAAAAABOw/8hdT1YRp9i0/s1600/sccp.JPG]

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 addr essing 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 through out 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 0—Basic connectionless class - it has no sequencing control. i doe s not impose any condition on SLS, therefore SCCP message can be delivered in out-of-sequece. • Class 1—In-sequence delivery connectionless class - it adds the sequence control to class 0 service by requiring to insert the same SLS to all NSDU.


49/51

7/7/2014

The Telecom Protocols • Class 2—Basic 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 3—Flow 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.) Conne ction 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 a ll zeros. Usally Calling Party Address, etc in Optiona l 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 - Called Party Address Connection Refused (CREF): - Message Type - DLR - Refusal Cause - Called Party Address - Data Released (RLSD): - Message Type - DLR - SLR - Refusal Cause - Called Party Address - 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 - Called Party Address - Calling Party Address - Data 8.) A global title is an address, such as dialed- digits, which does not explicitly contain information that would allow


50/51

All Protocol Docs

Recommend Documents