All Protocol Docs

7/21/2019 All Protocol Docs

1/51

7/7/2014 The Telecom Protocols

http://telecomprotocols.blogspot.in/ 1/51

21st March 2013

SIP responses generated by the UAS or SIP servers.

SIP Response Classes:

1xx - Informational - Indicates the status of call prior to the completion.

2xx - Success - Request has succeeded.

3xx - Redirection - The client should try to complete the request at another server.

4xx - Client Error - The request has failed due to error due to the client. The client may retry.

5xx - Server failure - The request has failed due to server error. request may retry to another server.

6xx - Global failure - the request has failed and can not retry to any server.

1xx --Informational:

100 Trying: This response is used to indicate the next node receives the request and stop the retransmission. This

response is sent if there is delay in sending the final response more the 200ms.

180 Ringing: The response is generated if UA receives the INVITE and started the ringing. It may used to initiate local

ring back.

181 Call is being Forwarded: This response is indication of call is being forwarded to different destination.

182 Call Queued: The called server is overloaded or temporary unavailable. the server sends this status code to

queue the call. When server ready to take the call, it initiates appropriate final response.

183 Call Progress: This response may be used to send extra information for a call which is still being set up.

199 Early Dialog Terminated:Can be used by User Agent Server to indicate to upstream SIP entities (including the

User Agent Client (UAC)) that an early dialog has been terminated.

2xxSuccessful Response s

200 OK:Indicates the request was successful.

202 Accepted: Indicates that the request has been accepted for processing, but the processing has not been

completed.

204 No Notification: Indicates the request was successful, but the corresponding response will not be received.

3xxRedirection Response

300 Multiple 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 update any records o f the original Request-URI with the new value.

302 Moved Temporarily:The client should try at the address in the Contact field. If an Expires field is present, the

client may cache the result for that period of time.

305 Use Proxy: The Contact field details a proxy that must be used to access the requested destination.

380 Alternative Service: The call failed, but alternatives are detailed in the message body.

4xxClient Failure Responses

400 Bad Reque st: The request could not be understood due to malformed syntax.

401 Unauthorized:The request requires user authentication. This response is issued by UASs and registrars.

402 Payment Require d:Reserved for future use.

403 Forbidden: The server understood the request, but is refusing to fulfill it

404 Not Found: The server has definitive information that the user does not exist at the domain specified in the

Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handledby the recipient of the request.

405 Method Not Allowed:The method specified in the Request-Line is understood, but not allowed for the address

identified by the Request-URI.

406 Not Acceptable:The resource identified by the request is only capable of generating response entities that have

content characteristics but not acceptable according to the Accept header field sent in the request.

407 Proxy Authentication 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: 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: 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 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:The received request contains a Session-Expires header field with a duration below

the minimum timer.

423 Interval Too Brief:Expiration time of the resource is too short.

SIP Responses

Dynamic V iew s template. Template images by chuwy . Pow ered by Blogger.

Classic

The Telecom Protoc search
http://www.istockphoto.com/googleimages.php?id=6215132&platform=blogger&langregion=enhttp://www.blogger.com/http://telecomprotocols.blogspot.com/2013/03/sip-responses.htmlhttp://telecomprotocols.blogspot.in/http://telecomprotocols.blogspot.in/http://telecomprotocols.blogspot.in/?view=timeslidehttp://telecomprotocols.blogspot.in/?view=snapshothttp://telecomprotocols.blogspot.in/?view=sidebarhttp://telecomprotocols.blogspot.in/?view=mosaichttp://telecomprotocols.blogspot.in/?view=magazinehttp://telecomprotocols.blogspot.in/?view=flipcardhttp://telecomprotocols.blogspot.in/?view=classichttp://www.blogger.com/http://www.istockphoto.com/googleimages.php?id=6215132&platform=blogger&langregion=enhttp://telecomprotocols.blogspot.com/2013/03/sip-responses.htmlhttp://telecomprotocols.blogspot.com/2013/03/sip-responses.html


2/51



424 Bad Location Information: The request's location content was malformed or otherwise unsatisfactory.

428 Use Identity Header: The server policy requires an Identity header, and one has not been provided.

429 Provide Referrer Identity: The server did not receive a valid Referred-By token on the request.

430 Flow Failed: A specific flow to a user agent has failed, although other flows may succeed. This response is

intended for use between proxy devices, and should not be seen by an endpoint (and if it is seen by one, should be

treated as a 400 Bad Request response).

433 Anonymity Disallowed:The request has been rejected because it was anonymous.

436 Bad Identity-Info: The request has an Identity-Info header, and the URI scheme in that header cannot be

dereferenced.

437 Unsupported Certificate: The server was unable to validate a certificate for the domain that signed the request.

438 Invalid Identity Header: The server obtained a valid certificate that the request claimed was used to sign the

request, but was unable to verify that signature.

439 First Hop Lacks Outbound Support: The first outbound proxy the user is attempting to register through doesnot support the "outbound" feature of RFC 5626, although the registrar does.

470 Consent Needed: The source of the request did not have the permission of the recipient to make such a request.

480 Temporarily Unavailable: Callee currently unavailable.

481 Call/Transaction Does Not Exist: Server received a request that does not match any dialog or transaction.

482 Loop Detected: Server has detected a loop.

483 Too Many Hops: Max-Forwards header has reached the value '0'.

484 Address Incomplete : Request-URI incomplete.

485 Ambiguous: Request-URI is ambiguous.

486 Busy Here : Callee is busy.

487 Request Terminated: Request has terminated by bye or cancel.

488 Not Acceptable 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 body, which recipient can not decrypt.

494 Security Agreement Required: The server has received a request that requires a negotiated security

mechanism, and the response contains a list of suitable security mechanisms for the requester to choose between or a

digest authentication challenge.

5xxServer Failure Responses

500 Server Internal Error: The server could not fulfill the request due to some unexpected condition.

501 Not Implemented: The server does not have the ability to fulfill the request, such as because it does not

recognize the request method. (Compare with 405 Method Not Allowed, where the server recognizes the method but

does not allow or support it.)

502 Bad Gateway: The server is acting as a gateway or proxy, and received an invalid response from a downstream

server while attempting to fulfill the request.

503 Service Unavailable: The server is undergoing maintenance or is temporarily overloaded and so cannot process

the request. A "Retry-After" header field may specify when the client may re attempt its request.

504 Server Time-out: The server attempted to access another server in attempting to process the request, and did

not receive a prompt response.

505 Version Not Supported: The SIP protocol version in the request is not supported by the server513 Message Too Large: The request message length is longer than the server can process.

580 Precondition Failure: The server is unable or unwilling to meet some constraints specified in the offer.

6xxGlobal Failure 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 2013by Pramod Kumar

Labels: SIP

0 Add a comment

20th March 2013

SIP Servers:

Proxy Servers:

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

SIP Methods
http://telecomprotocols.blogspot.com/2013/03/sip-methods.htmlhttp://telecomprotocols.blogspot.com/2013/03/sip-methods.htmlhttp://telecomprotocols.blogspot.in/search/label/SIPhttps://plus.google.com/101859675701337156217


3/51



parsed, processed, and forwarded or responded to,no information about the message is storedno dialog information is s tored. A

stateless proxy never re-transmits a message, and does not use any SIP timers.

-A stateful proxy serverkeeps track of requests and responses received in the past and uses that information in processing future

requests and responses. For example, a stateful proxy server starts a timer when a request is forwarded. If no response to the

request is received within the timer period, the proxy will

re-transmit the request, relieving the user agent of this task. Also, a stateful proxy c an require user agent authentication.

Back-to-Back User Agents (B2BUA):

An B2BUA is a type of SIP device that receives the SIP request, that reformulates the request and send it out as new request.

Response to the request are reformulated and sent back to the UA in opposite direction.

SIP Methods (Request):

1.) INVITE: The INVITE is used to establish the media session between the users. An Invite usually has a message

body containing the media session information as SDP. it also contains other information like QoS and security information. If

INVITE does not contain the media information, the ACK message contains the media information of the UAC.

A media session is considered established when the INVITE, 200 OK, and ACK messages have been exchanged between the UAC

and the UAS. If the media information contained in the ACK is not acceptable, then the called party must send a BYE to cancel the

sess ion, a CANCEL cannot be sent because the session is already established. A UAC that originates an INVITE to establish a

dialog creates a globally unique Call-ID that is used for the duration of the call. A CSeq count is initialized (which need not be set to

1, but must be an integer) and incremented for each new request for the same Call-ID. The To and From headers are populated

with the remote and local addresses. A From tag is included in the INVITE, and the UAS includes a To tag in any responses. A To

tag in a 200 OK response to an INVITE is used in the To header field of the ACK and all future requests within the dialog. The

combination of the To tag, From tag, and Call-ID is the unique identifier for the dialog.

Re-Invite: An INVITE sent for an existing dialog references the same Call-ID as the original INVITE and contains the same To and

From tags. Sometimes called a re-INVITE, the request is used to change the session characteristics or refresh the state of the

dialog. The CSeq command sequence number is incremented so that a UAS can distinguish the re-INVITE from a re-

transmission of the original INVITE.

UPDATE: A re-INVITE must not be sent by a UAC until a final response to the initial INVITE has been received instead, an

UPDATE request c an be sent.

AnExpires header in an INVITE indicates to the UAS how long the call request is valid. For example, the UAS could leave an

unanswered INVITE request displayed on a screen for the duration of specified in the Expires header. Once a s ession is established,

the Expires header has no meaning, the expiration of the time does not terminate the media session. Instead, a Session-Expires

header can be used to place a time limit on an established 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:registrar.text.com SIP/2.0

Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bKus1812

Max-Forwards: 70

To: Marconi

From: Marconi

;tag=3431

Call-ID: [email protected]

CSeq: 1 REGISTER

Contact: sip:[email protected]

Content-Length: 0

--------------------------------------------------------

SIP/2.0 200 OK

Via: SIP/2.0/UDP 200.201.202.203:5060;branch=z9hG4bKus19

To: Marconi ;tag=8771

From: Marconi

;tag=3431


CSeq: 1 REGISTER

Contact:Marconi ;expires=3600

Content-Length: 0

--------------------------------------------------------

The Contact URI is returned along with an expires parameter, which indicates how long the registration is valid, which in this case

is 1 hour (3,600 seconds).

Marconi Registrar Server

=================================

--------------REGISTER--------------------->


4/51



Max-Forwards:70


From: Te la ;tag=9341123


CSeq: 12 BYE

Content-Length: 0

4.) ACK: The ACK method is used to acknowledge final responses to INVITE requests. F inal responses to all other

requests are never acknowledged. Final responses are defined as 2xx, 3xx, 4xx, 5xx, or 6xx class responses. The CSeq

number is never incremented for an ACK, but the CSeq method is changed to ACK. This is so that a UAS can match

the CSeq number of the ACK with the number of the corresponding INVITE.

An ACK may contain an application/sdp message body. This is permitted if the initial INVITE did not contain a SDP

message body. If the INVITE contained a message body, the ACK may not contain a message body. The ACK may not

be used to modify a media description that has already been sent in the initial INVITE; a re-INVITE must be used for this

purpose.

For 2xx responses, the ACK is end-to-end, but for all other final responses it is done on a hop-by-hop basis when

stateful proxies are involved. The end-toend nature of ACKs to 2xx responses allows a message body to be

transported. A hop-by-hop ACK reuses the same branch ID as the INVITE since it is considered part of the same

transaction. An end-to-end ACK uses a different branch ID as it is considered a new transaction.

ACK sip:[email protected] SIP/2.0

Via: SIP/2.0/TCP 100.200.102.100:5060;branch=z9hG4bK1234

Max-Forwards:70


From: Tesla ;tag=887823


CSeq: 3 ACK

Content-Type: application/sdp

Content-Length: 100

(SDP not shown)

5.) CANCEL:The CANCEL method is used to terminate pending call attempts. It can be generated by either user

agents or proxy servers provided that a 1xx response containing a tag has been received, but no final response has

been received. CANCEL is a hop-by-hop request and receives a response generated by the next stateful element. The

CSeq is not incremented for this method so that proxies and user agents can match the CSeq of the CANCEL with the

CSeq of the pending INVITE to which it corresponds. The branch ID for a CANCEL matches the INVITE that it is

canceling.

CANCEL sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 100.100.122.122:5060;branch=z9hG4bK3134324

Max-Forwards:70

To: Marconi



CSeq: 1 CANCEL

Content-Length: 0

6.) OPTIONS: The OPTIONS method is used to query a user agent or server about its capabilities and discover its

current availability. The response to the request lists the

capabilities of the user agent or server. A proxy never generates an OPTIONS request.

OPTIONS sip:[email protected] SIP/2.0

Via: SIP/2.0/UDP 100.200.100.100;branch=z9hG4bK1834

Max-Forwards:70

To: Marconi

From: Tesla

;tag=34


CSeq: 1 OPTIONS

Content-Length: 0

7.) REFER:The REFER method is used by a user agent to request another user agent to access a URI or URL

resource. The resource is identified by a URI or URL in the required Refer-To header field. When the URI is a sip or

sips URI, the REFER is probably being used to implement a call transfer service. REFER can also used to implement

peer-to-peer call control.

REFER sip:[email protected] SIP/2.0

Via SIP/2.0/UDP test.com:5060;branch=z9hG4bK9323249

Max-Forwards: 69

To: ;tag=324234


Call-ID: 3419fak32343243s1A9dkl


5/51



CSeq: 5412 REFER

Refer-To:

Content-Length: 0

8.) SUBSCRIBE: The SUBSCRIBE method is used by a user agent to establish a subscription for the purpose of

receiving notifications (via the NOTIFY method) about a particular event. The subscription request contains an Expires

header field, which indicates the desired duration of the existence of the subscription. After this time period passes, the

subscription is automatically terminated. The subscription can be refreshed by sending another SUBSCRIBE within the

dialog before the expiration time. A server accepting a subscription returns a 200 OK response also obtaining an

Expires header field. There is no UNSUBSCRIBE method used in SIPinstead a SUBSCRIBE with Expires:0 requests

the termination of a subscription and hence the dialog. A terminated subscription (either due to timeout out or a

termination request) will result in a final NOTIFY indicating that the subscription has been terminated.

UA Proxy-Server Presence Agent

====================================

------------Subscribe----------->

-----------Subscribe-------------->


6/51



- 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 2013by Pramod Kumar

Labels: Call Flows,Codec Management,VOIP (Voice over IP)

0 Add a comment

3rd December 2012

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

[http://4.bp.blogspot.com/-J59OmJgtxwM/ULxV9a5i0aI/AAAAAAAABPg/1DYT1mqCKWs/s1600/interfaces.JPG]

Network Interf aces and Protocols

Posted 3rd December 2012by Pramod

Labels: Codec Management

Core Network Architecture - Interfaces

0 Add a comment

23rd October 2012

Codec Management has following goals:

1.) Optimize the voice quality.

2.) Optimize the bandwidth efficiency

3.) Optimize the transcoder resource in MGW.4.) Optimize the delay

Voice quality is measured in terms of the level, attenuation, delay, echo, and so on and may be used as a basis for the

iQoS assessments for conventional VoIP. Voice Quality is measured in terms of R-value and below 50 are not

Codec Management

Codec Management Objectives

Voice Quality:
http://telecomprotocols.blogspot.com/2012/10/codec-management.htmlhttp://telecomprotocols.blogspot.com/2012/10/codec-management.htmlhttp://telecomprotocols.blogspot.com/2012/12/core-network-architecture-interfaces.htmlhttp://telecomprotocols.blogspot.in/search/label/Codec%20Managementhttp://www.blogger.com/profile/14719317053870413519http://4.bp.blogspot.com/-J59OmJgtxwM/ULxV9a5i0aI/AAAAAAAABPg/1DYT1mqCKWs/s1600/interfaces.JPGhttp://telecomprotocols.blogspot.com/2012/12/core-network-architecture-interfaces.htmlhttp://telecomprotocols.blogspot.in/search/label/VOIP%20(Voice%20over%20IP)http://telecomprotocols.blogspot.in/search/label/Codec%20Managementhttp://telecomprotocols.blogspot.in/search/label/Call%20Flowshttps://plus.google.com/101859675701337156217


7/51



recommended.

Standards Intrinsic quality (R)

------------------------------------------------------

ITU G.711(64kbps) 94.3

ITU G.728 (12.kbps) 74.3

ETSI GSM-FR(13kbps) 74.3

ETSI GSM-HR (5.6kbps) 71.3

ETSI GSM-EFR(12.2kbps) 89.3

-----------------------------------------------------

Transcoding can be harmful for voice quality of a call and should be avoided if possible. In 2G, BSC is in charge oftranscoding while MSC is the incharge of transcoding in 3G. We have intention to minimise the Transcoder

to enhance the voice quality.

[http://1.bp.blogspot.com/-MC4wZ4nx8ZI/UIY4bi3uelI/AAAAAAAAAKE/MrBbw85JEuY/s1600/codec1.JPG]

Legacy networks use a consistent 64 kbps per channel. Use G.711, packet networks easily surpass 64 kbps.

Therefore , compress codecs must be used on core. Compression ratio of 8:1can be achieved with compressed

codecs along with the following techniques : silence suppression, AAL2/RTP multiplexing, IP header compression.

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

be used whenever possible.

Delay can be minimizedif reduce the number of transcoders. We can reduce the transcoding time in call.

Posted 23rd October 2012by Pramod Kumar


Bandwidth efficiency:

Transcoder Resource s optimization:

Optimization of delay:

0 Add a comment

19th October 2012

In Early legacy telephone network, A call between the two mobiles involved with two transcoding function at both the

end which decrease the voice quality. The Transcoding Function done by the TRAU (Transcoding and Rate Adaptation

Unit) to compress and decompress the speech.

TFO (Tandem Free Operation)enables to avoid the traditional double speech encoding / decoding in MS to MS callconfigurations. TFO uses in-band signalling and procedures for transcoders to enable compressed speech to be

maintained between a pair of transcoders.

So the main objective of TFO is the improvement of the voice quality for calls between 2 mobile subscribers, but no

resource optimisation is introduced as transcoder functions are always present in the path.

If TFO is activated between two end nodes, TFO Frames with compressed speech (e.g. AMR in LSB) as payload are

TFO - Tandem Free Operation
http://telecomprotocols.blogspot.com/2012/10/tfo-tandem-free-operation.htmlhttp://telecomprotocols.blogspot.com/2012/10/tfo-tandem-free-operation.htmlhttp://telecomprotocols.blogspot.in/search/label/Codec%20Managementhttps://plus.google.com/101859675701337156217http://1.bp.blogspot.com/-MC4wZ4nx8ZI/UIY4bi3uelI/AAAAAAAAAKE/MrBbw85JEuY/s1600/codec1.JPG


8/51



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 2012by Pramod Kumar


0 Add a comment

17th October 2012

In Early legacy telephone network, A call between the two mobiles involved with two transcoding function at both the

end which decrease the voice quality. The Transcoding Function done by the TRAU (Transcoding and Rate Adaptation

Unit) to compress and decompress the speech.

Transcoder Free Operation (TrFO) is transport of compressed speech, which eliminates unnecessary coding and

decoding of the signals when both end uses the same codecs. TrFO utilizes out of band signaling capabilities that

include the ability to determine the negotiated codec type to be used at the two end nodes. If the two end nodes are

capable of the same codec operations, it may be possible to traverse the entire packet network using only the

compressed speech (of the preferred codec). TrFO is basic function of codec Management.

Following are the benefits of achieving the TrFO:

1.) Improve the voice quality because of elimination of coding and decoding of suppressed codecs.

2.) We can optimize the resources by skipping the transcodes at both ends.

3.) We can increase the bandwidth in the Core Network.

4.) Increase the transmission delay by skipping the compression and decompression to G.711 codec.

It can improve the voice quality and above features using the TrFo and TFO simultaneously.

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

gETJBRJA6do/UH5hAFlaI4I/AAAAAAAAAJc/moj04H3ZQuI/s1600/Trfo.jpg]

TrFO Operation



TrFO - Transcoder Free Operation

5 View comments
http://telecomprotocols.blogspot.com/2012/10/trfo-transcoder-free-operation.htmlhttp://telecomprotocols.blogspot.in/search/label/Codec%20Managementhttps://plus.google.com/101859675701337156217http://4.bp.blogspot.com/-gETJBRJA6do/UH5hAFlaI4I/AAAAAAAAAJc/moj04H3ZQuI/s1600/Trfo.jpghttp://telecomprotocols.blogspot.com/2012/10/trfo-transcoder-free-operation.htmlhttp://telecomprotocols.blogspot.in/search/label/Codec%20Managementhttps://plus.google.com/101859675701337156217http://2.bp.blogspot.com/-cdr2NJlVsYM/UIEVctA-oiI/AAAAAAAAAJw/A2Whhqdc0sU/s1600/tfo.jpg


9/51



11th October 2012

HEX VALUE CAUSE

----------------------------------------------------------------

03 No route to destination

06 Channel unacceptable

08 Preemption

0E Query on Release QoR

10 Normal clearing

11 User busy

12 No user responding

13 No answer from user (user alerted)

14 Subscriber absent

15 Call rejected

16 Number changed

17 Redirection to new destinat ion

18 Call rejected because of a feature at the destinat ion

19 Exchange routing error

1A Non selected user clearing

1B Destinat ion out of Order1C Invalid number format (address incomplete)

1D Facility rejected

1E Response to Status Enquiry

1F Normal, unspecified

22 No circuit/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 exist

54 Call identity in use

57 User not member of Closed User Group

58 Incompatible destinat ion

5F Invalid message, unspecified

60 Mandatory information element is miss ing

6F Protocol error, unspecified

7F Interworking, unspecified


Labels: SS7 Protocol Stack

ISUP Release Cause Values

0 Add a comment

11th October 2012

Serv ice Name HEX BINARY

==================================================

CLIP 11 00010001

CLIR 12 00010010

COLP 13 00010011

COLR 14 00010100

All Call Forward 20 00100000

CFU 21 00100001

All Conditional call forward 28 00101000

CFB 29 00101001

CFNRY 2A 00101010

CFNRc 2B 00101011

CD 24 00100100

ECT 31 00110001

CW 41 01000001

CH 42 01000010

CCBs-A 43 01000011CCBs-B 44 01000011

MPTY 51 01010001

AOCI (information) 71 01110001

AOCC (Charging) 72 01110010

All call Barring 90 10010000

Outgoing call Barring 91 10010001

Supplementary Service Codes
http://telecomprotocols.blogspot.com/2012/10/supplementary-service-codes.htmlhttp://telecomprotocols.blogspot.com/2012/10/supplementary-service-codes.htmlhttp://telecomprotocols.blogspot.com/2012/10/isup-release-cause-values.htmlhttp://telecomprotocols.blogspot.in/search/label/SS7%20Protocol%20Stackhttps://plus.google.com/101859675701337156217http://telecomprotocols.blogspot.com/2012/10/isup-release-cause-values.html


10/51



baoc 92 10010010

boic 93 10010011

boicExHC 94 10010100

Barring of Incoming calls 99 10011001

baic 9A 10011010

bicRoam 9B 10011011

Abbreviation:

CLIP: Calling Line Identification Presentation

CLIR: Calling Line Identification RestrictionCOLP: Connected Line Identification Presentation

COLR: Connected Line Identification Restriction

CFU: Call Forwarding Unconditional

CFB: Call Forwarding Busy

CFNRy: Call Forwarding No Reply

CFNRc: Call Forwarding Not Reachable

ECT:Explicit Call Transfer

CW: Call Waiting

MPTY: Multi Party

CH: Call Hold

AOCI: Advice of Charge Indicator

BAOC: Barring of All Outgoing Calls

BOIC: Barring of outgoing International calls

BAIC: Barring of All Incoming Calls

BIC-ROAM: Barring of all incoming call while roaming.


Labels: GSM

0 Add a comment

9th October 2012

Here is UMTS subscriber call flow with the core network.

MS-A MSC MS-B****************************************************************************************************

------- Initial_UE(CM_SERVICE_REQ) -->|

------------Dir_Trnx(AUTH_REQ) |

---------------SecurityModeCmd |

-----Dir_Trnx(TMSI_RELOC_CMD) |

------ ------ -Dir_Trnx(SETUP) -->|

---------Dir_Trnx(CALL_PROC) PAGING ------ ------ ------- ------ --

| Dir_Trnx(AUTH_REQ)----- ------- --| SecurityModeCmd ------ ------- ------

| Dir_Trnx(TMSI_RELOC_CMD)------

| Dir_Trnx(SETUP) ------- ------ ------

| RabAssignReq ------------------------

|


11/51



|--> IuReleaseCmd ------ ------ ------- ------ --

|9, MNC2->7 MNC: 97

00 01 LAC: 1.Represent LAC in hex and put in two bytes

00 01 CI: 1 represents CI in hex and put in two bytes

17 12 message type and length of layer3

05 TI flag, value and protocol discriminator (Mobility management).

08 message type of LU

70 Chiperkey sequence No.

13 f0 79 ff fe Location Area Identification

30 08 89 88 88 12 45 12 00 00 IMSI

21 01 00 Mobility Management.

********************************************

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

01 Message Discriminator

Location Update Message Decoding

Location Update Flow :

CM Service Request/Location Update Request

Authentication Request
http://telecomprotocols.blogspot.com/2012/10/location-update-message-decoding.htmlhttp://telecomprotocols.blogspot.com/2012/10/location-update-message-decoding.htmlhttp://telecomprotocols.blogspot.in/search/label/Call%20Flowshttps://plus.google.com/101859675701337156217


12/51



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

13 Length (19)

05 Mobility Management

12 Message Type DTAP

01/02 Possible value for ciphering key sequence number

00 00 00 00 00 00 00 00 00 Authentication RAND

00 00 00 00 00 00 00

**********************************************

01 00 06 05 54 00 00 00 00



06 Length (06)


54 Message Type

00 00 00 00 Authentication SRES

*************************************************

00 01 58


01 Length (1)

58 Message Type

***********************************

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

00 Message Discriminator0b Length (10)

54 Message Type

12 Classmark Information Type 2

03 Length (03)

30 59 81 Class Mark

13 Classmark Information Type 3

02 Length (02)

60 14 Class Mark

00 end of Optional parameters.

********************************************

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


0e Length (15)

53 Message Type

0a Encryption Information

09 Length (09)

07 00 00 00 00 00 00 00 00 Encryption Information

23 Cipher Response Mode (Phase 2)

01 Spare/ IMEISV must be Included By The Mobile Station

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


10 Length (17)

55 Message Type

20 Layer 3 Message contents (Phase 2)

Authentication Response

Class Mark Request

Class Mark Update

Cipher Mode Command

Cipher Mode Complete


13/51



0b Length (11)

17 09 33 05 70 87 70 35 17 01 f9 Contents

2c Chosen Encryption Algorithm

01 No Encryption used

********************************************

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



0e Length (15)


02 Message Type

13 F0 MCC1-> 3, MCC2 ->1, MCC3-> 0 MCC: 310

69 MNC1->9, MNC2->6 MNC: 96

00 03 LAC

17 Mobility Identity

05 Parameter Length

f4 ST 0/Even Number of Address Signals / TMSI

0f 2f 20 04 00 02 01 Identity Digits

******************************

00 04 20 04 01 09


04 Length (04)

20 Message Type

04 Cause

01 Length

09 Extension bit (last octet) / Call Control Normal Event

*****************************

00 01 21


01 Length (1)

21 Message Type


Labels: Call Flows

Location Update Accept

Clear Command

Clear Complete

2 View comments

27th September 2012

The Signalling 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 0Basic connectionless class - it has no sequencing control. i does not impose any condition on SLS,

therefore SCCP message can be delivered in out-of-sequece.

Class 1In-sequence delivery connectionless class - it adds the sequence control to class 0 service by requiring to

insert the same SLS to all NSDU.

Class 2Basic connection-oriented class - Assign the local reference numbers (SLR,DLR) to create logical

connection. it does not provide the flow control, loss, and mis-sequence detection.

SCCP Messages
http://telecomprotocols.blogspot.com/2012/09/sccp-messages.htmlhttp://telecomprotocols.blogspot.com/2012/09/ss7-protocol-stack-sccp.htmlhttp://telecomprotocols.blogspot.com/2012/09/sccp-messages.htmlhttp://telecomprotocols.blogspot.in/search/label/Call%20Flowshttps://plus.google.com/101859675701337156217


14/51




L7w1xQzk7wQ/UGP2Fhb-vLI/AAAAAAAAAI4/rBUclMCwTRI/s1600/sccp.JPG]

Class 3Flow control connection-oriented class - Class 3 is an enhanced connection-oriented service that offers

detection of both message loss and mis-sequencing

1.Connection Request (CR): Connection Request message is initiated by a calling SCCP to a called SCCP to request the

setting up of a signalling connection between two entities. On Reception of CR message, the called SCCP initiates the setup

signalling connection. CR message have the Source Local Reference (SLR) as an address of originating entity. It is used during

connection establishment phase by connection-oriented protocol class 2 or 3.

2. Connection Confirm (CC): Connection Confirm message is initiated by the called SCCP to indicate to the callingSCCP that it has performed the setup of the signaling connection. On reception of a Connection Confirm message, the

calling SCCP completes the setup of the signaling connection. CC message have the SLR as an address of called

entity and DLR as the address of originating entity. It is used during connection establishment phase by connection-

oriented protocol class 2 or 3.

3. Connection Refused (CREF): Connection Refused message is initiated by the called SCCP or an

intermediate node SCCP to indicate to the calling SCCP that the setup of the signalling connection has been

refused. It is used during connection establishment phase by connection-oriented protocol class 2 or 3.

4. Data Acknowledgement (AK): Data Acknowledgement message is used to control the window flow control mechanism,

which has been selected for the data transfer phase. It is used during the data transfer phase in protocol class 3.

5. Data Form 1 (DT1): A Data Form 1 message is sent by either end of a signalling connection to pass transparently

SCCP user data between two SCCP nodes. It is used during the data transfer phase in protocol class 2 only.

6. Data Form 2 (DT2): A Data Form 2 message is sent by either end of a signalling connection to pass transparently

SCCP user data between two SCCP nodes and to acknowledge messages flowing in the other direction. It is used

during the data transfer phase in protocol class 3 only.

7. Expedited Data (ED): An Expedited Data message functions as aData Form 2message 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 theReleasedmessage 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 transferphase in protocol class 3.

14. Reset Confirm (RSC): A Reset Confirm message is sent in response to a Reset Requestmessage 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
http://1.bp.blogspot.com/-L7w1xQzk7wQ/UGP2Fhb-vLI/AAAAAAAAAI4/rBUclMCwTRI/s1600/sccp.JPG


15/51



SCCP Management (SCMG) at those destinations of the failure of a subsystem. It is used for SCCP subsystem

management.

16. Subsystem-Allowed (SSA): A Subsystem-Allowed message is sent to concerned destinations to inform those

destinations that a subsystem which was formerly prohibited is now allowed or that a SCCP which was formerly

unavailable is now available. It is used for SCCP management.

17. Subsystem-Status-Test (SST): A Subsystem-Status-Test message is sent to verify the status of a

subsystem marked prohibited or the status of an SCCP marked unavailable. It is used for SCCP management.

18. UnitData (UDT): A Unitdata message can be used by an SCCP wanting to send data in a connectionless mode. It

is used in connectionless protocol classes 0 and 1.

19. Unitdata Service (UDTS): A Unitdata Service message is used to indicate to the originating SCCP that a UDT sent

cannot be delivered to its destination. Exceptionally and subject to protocol interworking considerations, a UDTS might

equally be used in response to an XUDT or LUDT message. A UDTS message is sent only when the option field in that

UDT is set to "return on error". It is used in connectionless protocol classes 0 and 1.

20. Extended Unitdata (XUDT): An Extended Unitdata message is used by the SCCP wanting to send data (along with

optional parameters) in a connectionless mode. It is used for the segmentation of large message into more XUDT

messages. It is used in connectionless protocol classes 0 and 1.

21. Extended Unitdata Service (XUDTS): An Extended Unitdata Service message is used to indicate to

the originating SCCP that an XUDT cannot be delivered to its destination. It is used in connectionless protocol

classes 0 and 1.

22. Subsystem 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-of-

service, the request is transferred by means of a Subsystem-Out-of-Service-Request message between the SCCP atthe 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-Grantmessage is sent, in response to a

SubsystemOutofServiceRequest message, to the requesting SCCP if both the requested SCCP and the backup of

the affected subsystem agree to the request. It is used for SCCP subsystem management.

Posted 27th September 2012by Pramod Kumar

Labels: SS7 Protocol Stack

0 Add a comment

11th September 2012


rS3es3A3NQI/UEmDWcT8ipI/AAAAAAAAAH8/y2eJXo7pHAI/s1600/3gpp.JPG]

Why LTE? The first question came into mind is why LTE? we are having 2G and 3G well established in market, then

what is the requirement of LTE or so called 4G.

But before proceeding let me clear LTE is not considered as 4G but the 3.9G due to some limitation.

To answer the question, the subscribers and business users are discovered the power of wireless broadband through

the advanced phones. Today internet are used for video streaming, live video, You Tube, Maps, Social Sites and web

search.

Because of so much to do on internet, consumers wants the high speed in data transfer on the go and the solution is

LTE. The standards of LTE developed by 3GPP.

LTE Provides following features and application for users and business:

LTE - Long Term Evolution
http://telecomprotocols.blogspot.com/2012/09/lte-long-term-evolution.htmlhttp://4.bp.blogspot.com/-rS3es3A3NQI/UEmDWcT8ipI/AAAAAAAAAH8/y2eJXo7pHAI/s1600/3gpp.JPGhttp://telecomprotocols.blogspot.com/2012/09/lte-long-term-evolution.htmlhttp://telecomprotocols.blogspot.in/search/label/SS7%20Protocol%20Stackhttps://plus.google.com/101859675701337156217


16/51



Improve QoS by decreasing the latency time.

provide the connectivity for non-traditional device like cars

provide the communication, entertainments, personal assistance.

Improving the services

Reducing the transport network cost.

All IP Network (AIPN).

2G/3G vs LTE:

- 2G and 3G supports voice traffic on CS (Circuit Switched) Network and Data service on packet netwok

- LTE provides voice and data over IP (packet network); single channel End to End and all-IP. however current release

of LTE (3GPP Release 8) does not support voice over LTE.

LTE Architecture:

[http://3.bp.blogspot.com/-VOOHx-XOGpc/UEbrF1tT2lI/AAAAAAAAAHU/gUrMhig9kJ0/s1600/lte_archi.JPG]

Entity Summery:

MME (Mobile Management Entity): MME provides mobility and session control management.

SGW (Serving Gate way): Routes and forwards the user data packets.

PGW (PDN Gateway): Provides UE session connectivity to external packet data network (PDN).

PCRF: Supports service data flow detection, policy enforcement, and flow based charging.

eNodeB: Receive and sends radio signals to and from the antennas. Schedules uplink and downlink data to/from

the UE. Provides Ethernet links to the EPC elements and o ther eNodeB.

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/AAAAAAAAAHo/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 requires 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 require 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.
http://4.bp.blogspot.com/-gbZy-Kqvn-Q/UEcaBFvzKcI/AAAAAAAAAHo/AR9UNRVc1uA/s1600/lte_mimo.JPGhttp://3.bp.blogspot.com/-VOOHx-XOGpc/UEbrF1tT2lI/AAAAAAAAAHU/gUrMhig9kJ0/s1600/lte_archi.JPG


17/51



Communicates with the eNodeB and SGW for the session control and bearer setup.

MM E Interfaces:

S10:To other MMEs

S1-MME: MME to eNodeB

S6a:MME to HSS

S11: MME to HSS

S13: MME to EIR

X1_1 and X2: to IRI for Lawful interception

[http://3.bp.blogspot.com/-pymIzX984YY/UEmFVPeGUjI/AAAAAAAAAIM/9tLleQia-8U/s1600/lte_interfaces.JPG]

SGW Functionality:

Serves as local mobility anchor for the UE - terminates the packet data network interface towards the eUTRAN.

Support user-plan mobility - performs IP routing and forwarding functions and maintains data paths between the

eNodeBs and the PGW.

SGW Interfaces:

S5 from the PGW (User and Control traffic)

S8 from visiting SGW to Home PGW

S11 to the MME (For Control Traffic)

S1-U to the eNodeB (User Traffic)

PGW Functionality:

Provide the UE with the IP address.

Connect user to PDN.

Facilitates flow-based charging (Provides records to external billing systems)

Serves as the cross-techno logy mobility anchor (Support mobility between 3GPP/non-3GPP access to Non-

3GPP/3GPP access.

Per-User based packet filtering.

PGW interfaces:

S5 from the SGW ( for the user and control traffic)

S8 from the visiting SGW to Home PGW (Roaming, user and control traffic)

SGi to the packet data network (User traffic).

Gx to the PCRF (for the policy control)

PCRF Functionality:

Policy management entity that provides dynamic control of QoS and charging policies for the service data flows

(SDFs)

Decide how the SDFs will be treated by the PGW

On the UE attachments, the PCRF:

1. Receive the request for the policies for the default bearers.

2. Retrieve the user profiles from SPR and executes the rule-sets for the decision for the policy and charging.

3. Responds the PGW with the PCC rule.

PCRF Interfaces:

Gx to the PCRF (policy contol)

Sp to the SPR (For the subscriber repository).


Labels: 4G,LTE

0 Add a comment
http://telecomprotocols.blogspot.in/search/label/LTEhttp://telecomprotocols.blogspot.in/search/label/4Ghttps://plus.google.com/101859675701337156217http://3.bp.blogspot.com/-pymIzX984YY/UEmFVPeGUjI/AAAAAAAAAIM/9tLleQia-8U/s1600/lte_interfaces.JPG


18/51



10th September 2012

For call related message, there are two type of solutions defined for portability Domain:

A. Mobile Number Portability-Signaling Relay Function (MNP- SRF):it is based solution acts on

SCCP addressing and also makes use of NP database.

B. IN- Related Solution: IN based solution allows the MSCs to retrieve routing information f rom NPDB.

A. Mobile Number Portability-Signaling Relay Function (MNP- SRF) Scenarios:


dXBE3rrXxOI/UESRI3LAmtI/AAAAAAAAAD4/pz6-X_QeVVo/s1600/port_achitecture_MNP-SRF.JPG]

Figure- Call related case - Signalling Relay Function (SRF) solution

Call A.1: Call to a non-ported number:

[http://1.bp.blogspot.com/-ymwWPwa2w2I/UESJARDo5SI/AAAAAAAAADQ/pU7N7iI4zIY/s1600/non-ported.JPG]

MNP Call Flows
http://telecomprotocols.blogspot.com/2012/09/mnp-call-flows.htmlhttp://1.bp.blogspot.com/-ymwWPwa2w2I/UESJARDo5SI/AAAAAAAAADQ/pU7N7iI4zIY/s1600/non-ported.JPGhttp://1.bp.blogspot.com/-dXBE3rrXxOI/UESRI3LAmtI/AAAAAAAAAD4/pz6-X_QeVVo/s1600/port_achitecture_MNP-SRF.JPGhttp://telecomprotocols.blogspot.com/2012/09/mnp-call-flows.html


19/51



Fig 1: Call to a non-ported number

1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the subscription network being the

number range holder network, if the number is non-ported.

2. When GMSCa receives the ISUP IAM, , it requests routing information by submitting a MAP SRI to the

MNP_SRF/MATF.

3. When the MNP_SRF/MATF receives the message, the MNP_SRF/MATF analyses the MSISDN in the CdPA and

identifies the MSISDN as being non-ported. The MNP_SRF/MATF function then replaces the CdPA by an HLRB

address. After modifying the CdPA, the message is routed to HLRB.

4. When HLRB receives the SRI, it responds to the GMSCb by sending an SRI ack with an MSRN that identifies the

MSB in the VMSCb.5. GMSCb uses the MSRN to route the call to VMSCb.

6. IAM requires special NOA

Call A.2 : Call to the Ported Number Originating Network = Subscription Network Direct Routing:


Kij9u85sfCs/UESK4avA2rI/AAAAAAAAADY/XE0Ivwcd-mE/s1600/ported-direct.JPG]

Fig 2: Call to the Ported Number Originating Network = Subscription Network

1. MSA originates a call to MSISDN.

2. VMSCa routes the call to the networks GMSCa.

3. When GMSCa receives the ISUP IAM, it requests routing information by submitting a MAP SRI to the

MNP_SRF/MATF.

4. When the MNP_SRF/MATF receives the message, it analyses the MSISDN in the CdPA and identifies the MSISDN

as being ported into the network. The MNP_SRF/MATF function then replaces the CdPA by an HLRA address.

After modifying the CdPA, the message is routed to HLRA.

5. When HLRA receives the SRI, it responds to the GMSCa by sending an SRI ack with an MSRN that identifies the

MSB in the VMSCb.

6. GMSCa uses the MSRN to route the call to VMSCb.

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

Call A.3: Mobile Originated Call to a Ported or not known to be Ported Number OriginatingNetwork=Subscription Network Direct Routing
http://3.bp.blogspot.com/-Ulcgcb-y8Ps/UESOg7RSy6I/AAAAAAAAADo/mcYnuAk3Dps/s1600/ported-out.JPGhttp://3.bp.blogspot.com/-Ulcgcb-y8Ps/UESOg7RSy6I/AAAAAAAAADo/mcYnuAk3Dps/s1600/ported-out.JPGhttp://4.bp.blogspot.com/-Kij9u85sfCs/UESK4avA2rI/AAAAAAAAADY/XE0Ivwcd-mE/s1600/ported-direct.JPGhttp://3.bp.blogspot.com/-Ulcgcb-y8Ps/UESOg7RSy6I/AAAAAAAAADo/mcYnuAk3Dps/s1600/ported-out.JPG


20/51



y8Ps/UESOg7RSy6I/AAAAAAAAADo/mcYnuAk3Dps/s1600/ported-out.JPG]

Fig3: Mobile Originated Call to a Ported or not know n to be Ported Number Direct Routing

1. MSA originates a call to MSISDN.

2. VMSCA routes the call to the networks GMSCA.

3. When GMSCA receives the ISUP IAM, it requests routing information by submitting a MAP SRI to the

MNP_SRF/MATF.

4. When the MNP_SRF/MATF receives the message, it analyses the MSISDN in the CdPA and identifies

the MSISDN as not known to be ported or being ported to another network. As the message is a SRI

message, the MNP_SRF/MATF responds to the GMSCa by sending an SRI ack with a RN + MSISDN;

For the case the number is not known to be ported the routing number may be omitted.

5. GMSCa uses the (RN +) MSISDN to route the call to GMSCb in the subscription network. Depending on

the interconnect agreement, the RN will be added in the IAM or not.

Call 4: Call to a Ported Number Indirect Routing

[http://3.bp.blogspot.com/-ayYVUEYKKm4/UESQAgN-

doI/AAAAAAAAADw/silf4RmuMIQ/s1600/ported-indirect.JPG]

Fig4: Call to a Ported Number Indirect Routing

1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the number range holder network.

2. When GMSCa in the number range holder network receives the ISUP IAM, it requests routing information by

submitting a MAP SRI to MNP_SRF/MATF.

3. When the MNP_SRF/MATF receives the message, it analyses the MSISDN in the CdPA and identifies the MSISDN

as being ported to another network. As the message is an SRI message, the MNP_SRF/MATF responds to the

GMSCa by sending an SRI ack with a RN + MSISDN

4. GMSCa uses the RN + MSISDN to route the call to GMSCb in the subscription network. Depending on the

interconnect agreement, the RN will be added in the IAM or not.

Call A.5: Call to a Ported Number Indirect Routeing with Refere nce to Subscription Network

[http://3.bp.blogspot.com/-FtDddkt5tlY/UESUN3vxI2I/AAAAAAAAAEI/k_FEH4LO-rM/s1600/portedout_indirectrouting.JPG]

Fig5: Call to a Ported Number Indirect Routeing with Reference to Subscription Network
http://3.bp.blogspot.com/-FtDddkt5tlY/UESUN3vxI2I/AAAAAAAAAEI/k_FEH4LO-rM/s1600/portedout_indirectrouting.JPGhttp://3.bp.blogspot.com/-ayYVUEYKKm4/UESQAgN-doI/AAAAAAAAADw/silf4RmuMIQ/s1600/ported-indirect.JPGhttp://3.bp.blogspot.com/-Ulcgcb-y8Ps/UESOg7RSy6I/AAAAAAAAADo/mcYnuAk3Dps/s1600/ported-out.JPG


21/51



1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the number range holder network.

2. When GMSCA in the number range holder network receives the ISUP IAM, it requests routeing information by

submitting a MAP SRI to the MNP_SRF/MATF. The TT on SCCP may be set to SRI.

3. When MNP_SRF/MATF receives the message, MNP_SRF/MATF 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 relays the message to the subscription network by

adding a routeing number to the CdPA which information may be retrieved from a database. After modifying the

CdPA, the message is routed to the subscription network.

4. When MNP_SRF/MATF in the subscription network receives the SRI, it responds to the GMSCA in the number

range holder network by sending a SRI ack with a RN + MSISDN.

5. GMSCA uses the (RN +) MSISDN to route the call to GMSCB in the subscription network; Depending on the

interconnect agreement, the RN will be added in the IAM or not.

6. When GMSCB in the subscription network receives the ISUP IAM, it requests routeing information by submitting aMAP SRI to MNP_SRF/MATF. The TT on SCCP may be set to SRI.

7. When MNP_SRF/MATF receives the message, MNP_SRF/MATF operat ion is triggered. The MNP_SRF/MATF

functionality analyses the MSISDN in the CdPA and identifies the MSISDN as being ported into the network. The

MNP_SRF/MATF function then replaces the CdPA by an HLRB address which information may be retrieved from a

database. After modifying the CdPA, the message is routed to HLRB.

8. When HLRB receives the SRI, it responds to the GMSCB by sending an SRI ack with an MSRN that identifies the

MSB in the VMSCB.

9. GMSCB uses the MSRN to route the call to VMSCB.

B. IN- Related Solution:

The following network operator options are defined for the MT calls in the GMSC:

- Terminating call Query on Digit Analysis (TQoD)- Query on HLR Release (QoHR).

The following network operator option is defined for MO calls in VMSCA and for forwarded calls in the GMSC and

VMSCB:

- Originating call Query on Digit Analysis (OQoD).

Call B.1 Call to a non-ported number, no NP query required:

[http://4.bp.blogspot.com/-ho398TcUftU/UESWqM3-VVI/AAAAAAAAAEY/NaeROM5v7tA/s1600/non-ported_b.1.JPG]

Fig 6: Call to non-ported Number, no query required

1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the Number range holder network

being the Subscription network.

2. When GMSCB receives the ISUP IAM, it requests routeing information by submitting a MAP SRI to the HLRB

including the MSISDN in the request.

3. The HLRB requests an MSRN from the MSC/VLRB where the mobile subscriber currently is registered.

4. The MSC/VLRB returns an MSRN back to the HLRB.

5. The HLRB responds to the GMSCB by sending an SRI ack with an MSRN.


Call B.2: TQoD Number is not ported
http://4.bp.blogspot.com/-ho398TcUftU/UESWqM3-VVI/AAAAAAAAAEY/NaeROM5v7tA/s1600/non-ported_b.1.JPG


22/51



[http://4.bp.blogspot.com/-bh3pnZ6qySI/UESlPOKup8I/AAAAAAAAAEo/7EtdE5THQ8M/s1600/Tqod-Notported.JPG]

Fig 7: TQoD Number is not ported

1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the Number range holder network

being the Subscription network.2. When GMSCB receives the ISUP IAM, it will send a database query to the NPDB as a result of analysis of the

received MSISDN. The MSISDN is included in the query to the NPDB.

3. The NPDB detects that the MSISDN is not ported and responds back to the GMSCB to continue the normal call

setup procedure for MT calls.

4. The GMSCB requests 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.




Call B.3: TQoD Number is ported

[http://2.bp.blogspot.com/-grscysZP02M/UESl5CPCI-I/AAAAAAAAAEw/-JRbA8ane88/s1600/Tqod-ported.JPG]

Fig 8: TQoD Number is ported

1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the Number range holder network.

2. When GMSCA receives the ISUP IAM, it will send a database query, including the MSISDN, to the NPDB as a result

of analysis of the received MSISDN.3. The NPDB detects that the MSISDN is ported and responds back to the GMSCA with a Routeing Number pointing

out the Subscription network.

4. The call is routed to the Subscription network based on the Routeing Number carried in ISUP IAM message; also

the MSISDN is included in IAM.

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.
http://2.bp.blogspot.com/-grscysZP02M/UESl5CPCI-I/AAAAAAAAAEw/-JRbA8ane88/s1600/Tqod-ported.JPGhttp://4.bp.blogspot.com/-bh3pnZ6qySI/UESlPOKup8I/AAAAAAAAAEo/7EtdE5THQ8M/s1600/Tqod-Notported.JPG


23/51







Call B.4: QoHR Number is ported

[http://2.bp.blogspot.com/-plVAprSq4LE/UESm2iHYwVI/AAAAAAAAAE4/GFYIDDj14kc/s1600/HLR-ported.JPG]

Fig 9: QoHR Number is ported

1. From an Originating Exchange a call is set up to MSISDN. The call is routed to the Number range holder network.

2. When GMSCA receives the ISUP IAM, it requests routeing information by submitting a MAP SRI to the HLRA

including the MSISDN in the request.

3. The HLRA returns a MAP SRI ack with an Unknown Subscriber error since no record was found for the subscriber

in the HLRA.

4. When GMSCA receives the error indication form the HLRA, this will trigger the sending of a database query to the

NPDB, including the MSISDN in the query.5. The NPDB detects that the MSISDN is ported and responds back to the GMSCA with a Routeing Number pointing




7. The GMSCB requests routeing information by submitting a MAP SRI to the HLRB, including the MSISDN in the






Call B.5: OQoD Number is not ported
http://3.bp.blogspot.com/-bP5zgf-YFE8/UESnttyMlrI/AAAAAAAAAFA/9Ot94QcRh2c/s1600/Oqod-notported.JPGhttp://3.bp.blogspot.com/-bP5zgf-YFE8/UESnttyMlrI/AAAAAAAAAFA/9Ot94QcRh2c/s1600/Oqod-notported.JPGhttp://2.bp.blogspot.com/-plVAprSq4LE/UESm2iHYwVI/AAAAAAAAAE4/GFYIDDj14kc/s1600/HLR-ported.JPG


24/51



[http://3.bp.blogspot.com/-bP5zgf-YFE8/UESnttyMlrI/AAAAAAAAAFA/9Ot94QcRh2c/s1600/Oqod-notported.JPG]

Fig 10: OQoD Number is not ported

1. A call is initiated by Mobile Subscriber A towards Mobile Subscriber B, using the MSISDN of the called subscriber.

2. When VMSCA receives the call setup indication, it will send a database query to the NPDB as a result of analysis

of the received MSISDN, including the MSISDN in the query.

3. The NPDB detects that the MSISDN is not ported and responds back to the VMSCA to continue the normal call

setup procedure for MO calls. Depending on database configuration option, the NPDB could either return a

Routeing Number on not ported calls, as done for ported calls, or the call is further routed using the MSISDN

number only towards the Number range holder network.

4. The call is routed to the Number range holder/Subscription network based on the MSISDN or Routeing Number

carried in ISUP IAM message.5. The GMSCB requests routeing information by submitting a MAP SRI to the HLRB, including the MSISDN in the

request.





Call B.6: OQoD- Number is porte d

[http://3.bp.blogspot.com/-GzIWOpIYcxY/UESoqbnEO8I/AAAAAAAAAFI/Jg14ftyLyDY/s1600/Oqod-ported.JPG]

Fig 11: OQoD- Number is ported

1. A call is initiated by Mobile Subscriber A towards Mobile Subscriber B, using the MSISDN of the called subscriber.

2. When VMSCA receives the call setup indication, it will send a database query to the NPDB as a result of analysis

of the received MSISDN including the MSISDN in the query.

3. The NPDB detects that the MSISDN is ported and responds back to the VMSCA with a Routeing Number pointing




5. The GMSCB requests routeing information by submitting a MAP SRI to the HLRB, including the MSISDN in the







Labels: MNP,Mobile Number Portability

0 Add a comment

9th September 2012 H.248/MEGACO Protocol
http://3.bp.blogspot.com/-bP5zgf-YFE8/UESnttyMlrI/AAAAAAAAAFA/9Ot94QcRh2c/s1600/Oqod-notported.JPGhttp://telecomprotocols.blogspot.com/2012/09/h248megaco-protocol.htmlhttp://telecomprotocols.blogspot.com/2012/09/h248megaco-protocol.htmlhttp://telecomprotocols.blogspot.in/search/label/Mobile%20Number%20Portabilityhttp://telecomprotocols.blogspot.in/search/label/MNPhttps://plus.google.com/101859675701337156217http://3.bp.blogspot.com/-GzIWOpIYcxY/UESoqbnEO8I/AAAAAAAAAFI/Jg14ftyLyDY/s1600/Oqod-ported.JPGhttp://3.bp.blogspot.com/-bP5zgf-YFE8/UESnttyMlrI/AAAAAAAAAFA/9Ot94QcRh2c/s1600/Oqod-notported.JPG


25/51



H.248is 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 processing.

- TCP and UDP transport support

- Support either binary or text encoding.

Message Structure:

Message {

Transaction { Action {

Command {

Descriptor {

Package {

Property { }}}}}}

MTACDPP

Message: Multiple Transactions can be concatenated into a message, which contains header, the version, and one or

more Transactions.

Syntax: MEGECA /version [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)

Reply ( TID {CID})

The TID parameter must be the same as the corresponding transaction request. The CID must be specifying a value to

pertain to all responses for the actions.

Transaction Pending is invoked by the receiver indicates that the transaction is actively being processed, but has not

been completed. It is used to prevent the sender from assuming that the Transaction Request was lost if the

transaction takes some time to complete. The syntax for command is :

Pending ( TID {})

The TID must be same as the corresponding Transaction request.

The Root property normalMGExecutionTime is used to specify the interval within which the MGC expects a response

to any transaction from the MG. Another Root property normalMGCExecutionTime is used to indicate the interval within

which the MG should expect a response to any transaction from the MGC. Both of these properties are configurable by

the MGC and have the following value ranges

NormalMGExecutionTime = 100 to 5000 milliseconds

NormalMGCExecutionTime = 100 to 5000 milliseconds

Action: Action is a group of command to be executed in the same context. it does not have an own identifier.

Context is identified by a Context_ID, which is assigned by the MG when the first termination is Added to a context. The

context is deleted when the last termination is subtracted from a termination.

Command: Command are used to manipulate the logical entity of the protocol connection model, context and

termination. Commands provide the complete control of properties of the context and the terminations.

Commands are:

- ADD: The Add command adds a Termination to a Context. The first Termination add to a context creates a new

Context.

Request: Add = Termination_ID { [MediaDescriptor] [,EventDescriptor] [,SignalsDescritor] [,AuditDescriptor]}

Reply: Add = Termination_ID { [MediaDescriptor] [,EventDescriptor] [,SignalsDescritor][,ObservedEventsDescriptor][,StatisticsDescriptor] [,PackagesDescriptor] [,ErrorDescriptor] [,AuditDescriptor]}

- MODIFY: The Modify command modifies the properties, events and signals of a Termination.

Request: Modify = Termination_ID { [ MediaDescriptor] [,EventDescriptor] [,SignalsDescritor] [,AuditDescriptor]}


26/51



Reply: Modify = Termination_ID { [MediaDescriptor] [,EventDescriptor] [,SignalsDescritor]

[,ObservedEventsDescriptor] [,StatisticsDescriptor] [,PackagesDescriptor] [,ErrorDescriptor] [,AuditDescriptor]}

- SUBTRACT: The Subtract command disconnects a Termination from its Context and returns statistics on the

Termination's participation in the Context. The Subtract command on the last Termination in a Context deletes the

Context.

Request: Subtract = Termination_ID { [AuditDescriptor]}

Reply: Subtract = Termination_ID { [ MediaDescriptor] [,EventDescriptor] [,SignalsDescritor]

[,ObservedEventsDes[,StatisticsDescriptor[,PackagesDescriptor[,ErrorDescriptor] [,AuditDescriptor]}

- MOVE: The Move command atomically moves a Termination to another Context.

Request: Move = Termination_ID { [ MediaDescriptor] [,EventDescriptor] [,SignalsDescritor] [,AuditDescriptor]}

Reply: Move = Termination_ID { [ MediaDescriptor] [,EventDescriptor] [,SignalsDescritor]

[,ObservedEventsDescriptor] [,StatisticsDescriptor] [,PackagesDescriptor] [,ErrorDescriptor] [,AuditDescriptor]}

- Audit-value: The AuditValue command returns the current state of properties, events,

signals and statistics of Terminations.

Request: AuditValue = Termination_ID {AuditDescriptor}

Reply: AuditValue = Termination_ID { [MediaDescriptor] [,EventDescriptor] [,SignalsDescritor]

[,ObservedEventsDescriptor] [,StatisticsDescriptor] [,PackagesDescriptor]}

- Audit-Capability:Audit Capability commands returns the all possible propr ties, events, signals and statistics of the

Termination.

- Notify: The Notify command allows the MG to inform the MGC of the occurrence of events in the MG.

Request: Notify = Termination_ID { [,ObservedEventsDescriptor] [,ErrorDescriptor]}

Reply: Notify = Termination_ID { [ErrorDescriptor]}

- Service Change: The ServiceChange command allows the MG to notify the MGC that a Termination or group of

Terminations is about to be taken out of service or has just been returned to service. ServiceChange is also used by

the MG to announce its availability to a MGC (registration), and to notify the MGC of impending or completed restart of

the MG. The MGC may announce a handover to the MG by sending it a ServiceChange command. The MGC may also

use ServiceChange to instruct the MG to take a Termination or group of Terminations in or out of service.

Request: ServiceChange = Termination_ID { ServiceChangeDescriptor}

Reply: ServiceChange = Termination_ID { (ServiceChangeDescriptor/ ErrorDescriptor)}

Terminations:A Termination is a logical entity on a MG that sources and/or sinks media and/or control streams. A

Termination is described by a number of characterizing Properties, which are grouped in a set of Descriptors that are

included in commands. Terminations have unique identities (TerminationIDs), assigned by the MG at the time of their

creation.

There are two type of terminations:

Ephemeral Terminationsare created by means of an Add command. They are destroyed by means of a Subtract

command. These exist only for the duration of their use. These are created and destroyed.

Physical Termination: The physical terminations have the semi-permanent existence on the MGW. For example the

TDM channels that are exist as long as its provisioned on the MGW.

Context: Context is an association between collections of termination. There is special type of context called null

context, which contains the terminations that are not associated with any other termination.

Descriptors: Properties of the termination are organized syntactically into the descriptors. Parameters to the

commands are called Descriptors. Many commands share same descriptors.

- Modem Descriptors: Specifies the modem type and parameters.

- Multiplex Descriptors:Associates with the media and bearer in multimedia calls.

- Media Descriptors: Specifies the parameters of all media streams.These parameters are structured into two

descriptors: a TerminationState descriptor, which specifies the properties of a termination that are not stream

dependent and one or more Stream descriptorseach 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.


27/51



- Service Change Descriptors: Specifies the parameters between the MGC and MG when MG power up, termination

state change, MG or MGC failure happens, or MGC handoff.

- Digit Map Descriptors:A DigitMap is a dialing plan resident in the MG used for detecting and reporting digit events

received on a termination.

- Statistics Descriptors: The Statistics descriptor provides information describing the status and usage of a termination

during its existence within a specific Context.

- Package Descriptors: returns the list of package realized by the termination and it is used with the AuditValue

command.

- ObservedEvent Descriptors: notify event to MGC when detected used with the Notify Command.

- Topology Descriptors:A Topology descriptor is used to specify flow directions between terminations in a context. The

topology descriptor applies to a context instead of a termination.

- Error Descriptors: Specifies the Error code.

Package:

All properties, Events, Signals, and statistics used in the H.248 protocols are defined in packages. it is uniquely

identified by the packageID. Following are the Package defined:

- Generic (g): Signal Completion Event

- Base Root (root): Defines the generic 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 announcement functionality at a MG. Announcement will be played

endlessly by the MG, until the MGC stops the 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 2012by Pramod

Labels: H.248,MEGACO,VOIP (Voice over IP)

0 Add a comment

8th September 2012

Mobile Number Portability (MNP):

Mobile Number Portability (MNP) is the ability for a UMTS or GSM mobile subscriber to change the subscription network

within a portability domain while retaining her original MSISDN.

Mobile Number Portability (MNP)
http://telecomprotocols.blogspot.com/2012/09/mobile-number-portability-mnp.htmlhttp://telecomprotocols.blogspot.com/2012/09/mobile-number-portability-mnp.htmlhttp://telecomprotocols.blogspot.in/search/label/VOIP%20(Voice%20over%20IP)http://telecomprotocols.blogspot.in/search/label/MEGACOhttp://telecomprotocols.blogspot.in/search/label/H.248http://www.blogger.com/profile/14719317053870413519


28/51




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. This may or may not be

the Number range holder network.

For example if a subscriber is ported-out from Vodafone to Airtel, then Vodafone network if called as Donor network. If

this number range belongs to Vodafone then it also called NRHN so in this NRHN and Donor 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 as only Donor network and Idea would be NRHN.

Number Portability Database (NPDB): A Database which provides portability information like Number is ported out or

not (portability Status) and if ported out then provides the Routeing number (RN).

Routeing Number (RN): A Routeing number route the call to recipient network or subscription network. This is

provided by NPDB or MNP-SRF.

Number Portability Status: Information indicating the status of portability for Mobile subscriber. Portability can be:

- Own Number Ported Out

- Own Number not ported out

- Foreign number ported in- Foreign number ported out to foreign network.

- Foreign number not know to ported

Originating Network:Network where the calling party located.

Subscription Network or Recipient Network: An recipient network for the Mobile subscriber in porting process.

For Example if a number which is in process of porting is belongs to Vodafone network and ported out to Airtel, then

Airtel

would be Recipient Network in this case.

Following routing methods are mentioned: these are the method implemented in portability domain based on

the operator agreements.

- Direct Routing: Direct Routing of calls is PLMN options that allows to ro

All Protocol Docs

Documents

Transcript of All Protocol Docs