This is regarding your reply of my posting. Actually on this forum I did'nt see any link for telecom technology. That's why I posted the message.
Any way in these days there are so many technologies in market. Right now I am studying GSM technology. I need to know End to End call flow in GSM network. For eg. If some one from Delhi makes a call to other one at Mumbai and both have GSM mobile connection. Then What will be the call flow between various enties of network. Like Signal will go to BTS first from Mobile. ad what happen next.
I hope You will be intrested to discuss this thing. Please reply back.
once a mobile phone has successfully attached to a gsm network as described above, calls may be made from the phone to any other phone on the global pstn assuming the subscriber has an arrangement with their "home" phone company to allow the call.
The user dials the telephone number presses the send or talk key, and the mobile phone sends a call setup request message to the mobile phone network via the mobile phone mast (bts) it is in contact with.
The element in the mobile phone network that handles the call request is the visited mobile switching centre (visited msc). The msc will check against the subscriber's temporary record held in the visitor location registry to see if the outgoing call is allowed. If so, the msc then routes the call in the same way that a telephone exchange does in a fixed network. If the subscriber is on a pay as you go tariff (sometimes known as prepaid (for example, in australia and india)), then an additional check is made to see if the subscriber has enough credit to proceed.
If not, the call is rejected. If the call is allowed to continue, then it is continually monitored and the appropriate amount is decremented from the subscriber's account. When the credit reaches zero, the call is cut off by the network. The systems that monitor and provide the prepaid services are not part of the gsm standard services, but instead an example of intelligent network services that a mobile phone operator may decide to implement in addition to the standard gsm ones.
How incoming calls are made to a mobile
step one: contact the gateway msc when someone places a call to a mobile phone, they dial the telephone number (also called a msisdn) associated with the phone user and the call is routed to the mobile phone operator's gateway mobile switching centre. The gteway msc, as the name suggests, acts as the "entrance" from exterior portions of the pstn onto the provider's network.
As noted above, the phone is free to roam anywhere in the operator's network or on the networks of roaming partners, including in other countries. So the first job of the gateway msc is to determine the current location of the mobile phone in order to connect the call. It does this by consulting the home location register, which, as described above, knows which visitor location register the phone is associated with, if any.
Step two: determine how to route the call when the hlr receives this query message, it determines whether the call should be routed to another number (called a divert), or if it is to be routed directly to the mobile. •
if the owner of the phone has previously requested that all incoming calls be diverted to another number, known as the call forward unconditional (cfu) number, then this number is stored in the home location register. If that is the case, then the cfu number is returned to the gateway msc for immediate routing to that destination.
• if the mobile phone is not currently associated with a visited location register (because the phone has been turned off) then the home location register returns a number known as the call forward not reachable (cfnrc) number to the gateway msc, and the call is forwarded there. Many operators may set this value automatically to the phone's voice mail number, so that callers may leave a message. The mobile phone may sometimes override the default setting.
• finally, if the home location register knows that the phone is in the jurisdiction of a particular vlr , then it will request a temporary number (called an msrn) from that vlr. This number is relayed to the gateway msc, which uses it to route the call to another mobile switching center, called the visiting msc.
Step three: ringing the phone when the call is received by the visiting msc, the msrn is used to find the phone's record in the visited location register. This record identifies the phone's location area. Paging occurs to all mobile phone mast in that area. When the subscriber's mobile responds, the exact location of the mobile is returned to the visited msc.
The vmsc then forwards the call to the appropriate phone mast, and the phone rings. If the subscriber answers, a speech path is created through the visiting msc and gateway msc back to the network of the person making the call, and a normal telephone call follows. It is also possible that the phone call is not answered. If the subscriber is busy on another call (and call waiting is not being used) the visited msc routes the call to a pre-determined call forward busy (cfb) number. Similarly, if the subscriber does not answer the call after a period of time (typically 30 seconds) then the visited msc routes the call to a pre-determined call forward no reply (cfnry) number.
Once again, the operator may decide to set this value by default to the voice mail of the mobile so that callers can leave a message.
Thanks for this useful information. I was not aware about so much about this call flow. Exactly I did'nt know about operational flow like call charges etc. I have experience in technical side like how routing done, what are the interface between two entities etc. Any way thanks for your reply.
Now my next query is as follow.
In these days some companies (like spice mobiles ) are launching phone with dual technology (GSM + CDMA). Sincd GSM and CDMA are different technology , how a phone support dual sim feature?
Thanks for your reply. This is surely a very iseful information. I was not aware about operation procedure of GSM like call charges calculation. I have idea about technical side like interface between two entities. Any way Here is my next query.
In these days some companies like spice moble launched mobiles of dual sim i.e GSM and CDMA. Since both are diffrent technology. How one mobile support both feature?
Whenever we switch on mobile. MS sends some signals to BTS which is further forwarded to BSC, then PCU, then SGSN. Through these signals mobile tells SGSN that he is alive and ready to accept data. This procedure is Mobile Attachement Procedure.
I wish to know exact call flow during mobile attachment procedure.
A method for allocating corresponding identity (ID) to each of a plurality of base station controllers (BSC) and each of a plurality of base transceiver stations (BTS) in an international mobile telecommunication-2000 (IMT-2000) system including the plurality of BSCS, the plurality of BTSs and an OMC (OMC=operating and maintenance center) for managing the plurality of BSCs and the plurality of BTSs includes the steps of: by the OMC, determining if system initialization is performed; if the system initialization is not performed, going to the step a), otherwise by the OMC, transmitting BSC ID allocation data to all the BSCs coupled to the OMC and allocating corresponding specific BSC identities (IDs) and corresponding group IDs to all BSCs; by each of the plurality of BSCs, receiving the BSC ID allocation data from the OMC and recognizing a corresponding specific BSC ID and a corresponding group ID allocated to each BSC by analyzing the BSC ID allocation data; by each of the plurality of BSCs, transmitting BTS ID allocation data to all BTSs coupled to each BSC and allocating corresponding specific BTS IDs to all the BTSs; and by each of the plurality of BTSs, receiving the BTS ID allocation data from the BSC and recognizing corresponding specific BTS IDs allocated to each BTS by analyzing the BTS ID allocation data.
traditionally mobile network base transceiver stations (bts) have exchanged data with the core mobile network via a dedicated, high capacity connection to an associated base station controller (bsc), e.g., a dedicated t-l/e-1 line. In some cases, it may be desirable to use an ip or other packet data network to enable a bts to exchange data with a bsc. However, to meet quality of service obligations to carriers and/or provide a satisfactory call experience to users, care must be taken to ensure call data is communicated in an efficient manner that ensures safe and timely receipt at the destination.
 protocols such as the real-time transport protocol (rtp) have been provided to enable voice and similar data to be communicated reliably over an ip or other packet data network, however such protocols have associated with them certain overhead that consumes time and computing resources, e.g., to form headers, assign and track sequence numbers, etc.
In certain mobile telecommunication networks, the size of each packet (or frame) of voice data is relatively small, and packets are required to be sent relatively frequently (e.g., every 20 msec), making the overhead associated with protocols such as rtp more burdensome in relation to the amount of data being transmitted. In addition, rtp or other protocol header information must be communicated over the network, consuming network bandwidth and potentially introducing greater latency in network communications.
Therefore, there is a need for a way to maximize the voice or other call data transferred in relation to the overhead, network bandwidth use, and other resource consumption associated with the transport protocol used to transmit it. Brief description of the drawings  various embodiments of the invention are disclosed in the following detailed description and the accompanying drawings.  figure 1 is a block diagram illustrating elements of a typical gsm network.  figure 2 is a block diagram illustrating an embodiment of a mobile network with packet data network backhaul.
 figure 3 is a block diagram illustrating an example of a real-time transport protocol (rtp) packet.  figure 4 is a block diagram illustrating an embodiment of a real-time transport protocol (rtp) packet used to bundle call data.  figure 5 is a block diagram illustrating an embodiment of a slot data portion of the payload of a real-time transport protocol (rtp) packet used to bundle call- data.
 figure 6 is a flow chart illustrating an embodiment of a process for receiving and processing a real-time transport protocol (rtp) packet used to bundle call data.  figure 7 is a flow chart illustrating an embodiment of a process for bundling call data for multiple slots into a real-time transport protocol (rtp) packet. Detailed description  the invention can be implemented in numerous ways, including as a process, an apparatus, a system, a composition of matter, a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over optical or communication links. In this specification, these implementations, or any other form that the invention may take, may be referred to as techniques.
A component such as a processor or a memory described as being configured to perform a task includes both a general component that is temporarily configured to perform the task at a given time or a specific component that is manufactured to perform the task. In general, the order of the steps of disclosed processes may be altered within the scope of the invention.  a detailed description of one or more embodiments of the invention is provided below along with accompanying figures that illustrate the principles of the invention. The invention is described in connection with such embodiments, but the invention is not limited to any embodiment.
The scope of the invention is limited only by the claims and the invention encompasses numerous alternatives, modifications and equivalents. Numerous specific details are set forth in the following description in order to provide a thorough understanding of the invention. These details are provided for the purpose of example and the invention may be practiced according to the claims without some or all of these specific details. For the purpose of clarity, technical material that is known in the technical fields related to the invention has not been described in detail so that the invention is not unnecessarily obscured.  transporting call data efficiently via a packet data network is disclosed. In some embodiments, voice data for multiple calls (e.g., multiple tdm slots in the case of a gsm or other tdma network) is bundled into a single rtp (or similar) packet, under a single rtp (or other protocol) header.
On the receiving end, the rtp (or other) packet payload is parsed to identify and extract the call data for each call. In some embodiments, information included in the rtp (or other) header is used to parse the payload. In some embodiments, each portion of the payload includes a header containing data identifying the call/slot with which it is associated, a sequence number or data indicating how the data is to be used, and/or other information.  figure 1 is a block diagram illustrating elements of a typical gsm network. In the example shown, gsm network 100 includes a plurality of mobile devices 102 connected via base transceiver stations 104, represented in figure 1 by bts 106 and bts 108, to a base station controller (bsc) 110.
The bsc 110 has a packet control unit 112 associated with it, for handling non- voice network data communication (e.g., gprs) packets. The bts 's are connected to the bsc via abis links 114 and 116, respectively. The abis interface is a standards-based interface that typically includes one or more elements and/or requirements that are specific and' typically proprietary to an original equipment manufacturer (oem) and/or other vendor of the bsc. Typically, the abis interface/link is carried over a dedicated and private t-l/e-1 line. In the example shown, the bsc 110 is connected to a mobile switching center 118, to which the bsc 110 is configured to route inbound voice data received from mobile equipment via a bts and from which the bsc 110 is configured to receive outbound voice data.
The msc 118 connects to traditional telephone equipment and other networks via the public switched telephone network (pstn) 120. The msc 118 is connected via an ss7 (or other) network 122 to a home location register (hlr) 124 used to store subscriber data. To handle non- voice packet (e.g., gprs) data, the pcu 112 is connected to an sgsn 126. In the example shown sgsn 126 is connected via ss7 network 122 to hlr 124. Sgsn 126 is also connected via an ip network 128 and a ggsn 130 to the internet (or other external packet data network) 132.  figure 2 is a block diagram illustrating an embodiment of a mobile network with packet data network backhaul. In the example shown, the mobile network 200 includes mobile equipment 202 connected to a plurality of base transceiver stations represented in figure 2 by bts 204 and bts 206. Bts 204 and bts 206 are connected via a local internet access connection 205 and 207, respectively, to a packet data network (pdn) 208, such as the internet.
In some embodiments, mobile network data is sent, via pdn 208, between the base transceiver stations represented by bts 204 and bts 206, on the one hand, and agw 214, on the other, using the internet (ip) protocol. In various embodiments, internet access connections 205 and 207 comprise a cable, dsl, or other modem collocated with the bts and/or a local exchange carrier central office (lec-co) with dslam or cable head-end. Also connected to pdn 208 in the example shown in figure 2 is a router/firewall 210 connected to and configured to provide connectivity to and security with respect to an aggregation gateway 214, and a registration server 216.
In some embodiments, element management server ems 212 is connected to router/firewall 210. In some embodiments, router/firewall 210 is omitted and/or does not include a firewall. In various embodiments, element management server 212, an aggregation gateway 214, and a registration server 216 are included in one or more physical computing systems. Element management server 212 enables an administrator to perform operational, administrative, and/or management (oam) operations with respect to one or more mobile network elements, e.g., bts 204 or bts 206. Aggregation gateway (agw) 214 receives inbound mobile network data (voice, signaling, data, control/management) from one or more base transceiver stations (bts), via pdn 208, aggregates data from two or more base transceiver stations (if/as applicable), and provides the inbound data to bsc 218 via one or more physical ports, using time division multiplex (tdm) as prescribed by the gsm standard and the bsc oem's proprietary implementation of the abis interface 220.
In some embodiments, the agw 214 is capable of interfacing with more than one type of bsc, e.g., with bscs from two or more vendors. In some such embodiments, the agw 214 is configured and/or provisioned, e.g., at deployment time, to use the abis interface api of the particular type of bsc with which it is required to communicate in a particular installation. In some embodiments, an api or other interface specification or definition of the abis interface as implemented by each bsc vendor/oem the agw is desired to be able to support is obtained and used as applicable to configure/provision the agw to communicate with a particular bsc with which it is required to communicate.
In some embodiments, bsc 218 is connected to a pcu, such as pcu 112 of figure 1. In some embodiments, agw 214 is connected to a pcu. For example, bsc 218 is optional, and agw 214 directly connected to a pcu.  in some embodiments, agw 214 is configured to present two or more physical base transceiver stations to the bsc as a single logical bts, to more efficiently use bsc resources in situations in which each bts serves a relatively small service area and/or number of users. In some embodiments, agw 214 is configured to map communications received from the bsc to the correct physical bts and conversely to map communications received from two or more physical base transceiver stations to a single logical bts prior to forwarding such inbound communications to the bsc.  registration server 216 is configured to be used to register a bts and/or other provider equipment with the network, e.g., to authenticate the equipment prior to providing to the equipment session keys to be used in secure communication protocols, identifying (e.g., address) information for other network elements, such as agw 214, etc.
 each bts in the mobile network 200 shown in figure 2 in some embodiments handles only a small fraction of the call volume/load of a conventional bts, and in such embodiments agw 214 promotes more efficient use of limited bsc resources. For example, in some embodiments agw 214 aggregates data associated with multiple base transceiver stations and provides communication to/from the bsc via a fewer number of physical bsc ports (e.g., a single port). Li various embodiments, use of pdn 208 and agw 214 to transport data between base transceiver stations such as bts 204 and bts 206, on the one hand, and bsc 218, on the other, makes it commercially feasible to provide a small from factor and/or relatively low capacity bts for use in remote (e.g., rural) service areas and/or to provide dedicated service to individuals and/or relatively small groups of users, such as a household or small business, since in addition to not requiring a bsc port for each bts a dedicated t-l/e-1 line is not required.
 while the example shown in figure 2 and in other embodiments described herein involves a gsm network and/or uses gsm nomenclature to refer to network elements, the techniques described herein are applied in other embodiments to other types of mobile telecommunications networks, and in particular may be applied wherever a plurality of relatively low capacity base transceiver stations need to exchange mobile communication data with a base station controller or other node having a limited number of relatively very high capacity ports or other resources.  figure 3 is a block diagram illustrating an example of a real-time transport protocol (rtp) packet. The real-time transport protocol (rtp) is used in some embodiments to transport voice call data from a bts to an aggregation gateway, such as agw 214 of figure 2, via an ip and/or other packet data network.
In the example shown, rtp packet 300 is configured to be sent over an ip network using the udp transport protocol and therefore includes an ip header 302 and a udp header 304. Rtp packet 300 also includes rtp header 306 which includes information such as an rtp sequence number indicating the place of a particular packet in a sequence of packets associated with a call. Finally, rtp packet 300 includes a voice data payload 308, which in a typical prior art rtp implementation includes up to 40 bytes of call data associated with a single call.  figure 4 is a block diagram illustrating an embodiment of a real-time transport protocol (rtp) packet used to bundle call data. In some embodiments, an rtp packet with call data bundling, such as the rtp packet 400 of figure 4, is used to transport call data for multiples calls/channels, e.g., multiple tdma slots, in a single rtp packet. In some embodiments, such bundling minimizes the overhead associated with forming rtp packets and makes efficient use of available bandwidth on an ip and/or other data network used to transport call data, e.g., between a bsc/agw and a bts as described above.
The packet 400 includes an ip header 402, a udp header 404, and an rtp header 406. The packet 400 also includes up to 40 bytes of payload 408, divided among in this example eight tdm slots 0-7. In some embodiments, upon receipt at a destination (e.g., bts or agw) the headers 402-406 are removed and processed, and payload 408 is parsed to extract the enclosed data for up to eight slots, hi some embodiments, a particular rtp packet may include data for one up to a maximum number of slots (eight in this example), depending on the number of slots for which data was received and/or otherwise available on the sending end when the time to send the rtp packet arrived, which may depend in various embodiments on such factors as whether there is an active call associated with each slot and/or whether data associated with a call was lost or delayed or otherwise did not arrive in time to be included in the packet. In some embodiments a proprietary header included in the payload indicates how many slots worth of data are included. In some embodiments, the header specifies the slots for which data is included. In some embodiments, the payload is parsed to determine for how many and/or for which slots data is included in the payload 408. In some embodiments, for each slot the associated data includes a slot header with data associated with the slot data for that slot, such as an rtp or similar sequence number for the data associated with that slot.
While in the example shown in figure 4 up to eight slots worth of data may be included in payload 408, in other embodiments the maximum number of slots worth of data may be more or less, depending on such factors as the capacity, maximum packet size, and/or other characteristics. In some embodiments, the maximum number of slots for which call data is bundled into a single rtp packet is fourteen, representing a maximum of seven voice data slots for each of two transceivers at a bts. [0023j figure 5 is a block diagram illustrating an embodiment of a slot data portion of the payload of a real-time transport protocol (rtp) packet used to bundle call data. In some embodiments, the slot data portion 500 of figure 5 is included for each slot for which data is included in a payload portion of an rtp packet used to bundle call data, such as payload 408 of figure 4. The slot data portion 500 includes a slot header 502 containing data associated with the slot data, e.g., identifying the slot and/or other call information with which encoded voice packet and/or frame data included in the payload portion 504 of the slot data portion 500 is associated.
 figure 6 is a flow chart illustrating an embodiment of a process for receiving and processing a real-time transport protocol (rtp) packet used to bundle call data. In some embodiments, the process of figure 6 is implemented at an aggregation gateway and/or bsc for inbound call data received from a bts via an ip network and/or at a bts for outbound call data received from an aggregation gateway and/or bsc via an ip network. In the example shown, when an rtp packet is received (602) the payload portion is extracted and parsed (604) to obtain the enclosed data for at least one or up to a maximum number of slots. The slot data is then processed and for each slot the associated encoded voice data (packet and/or frame) is sent to its destination, e.g., sent via an abis link to a bsc in the case of inbound data received at an agw or transmitted via an air link to a mobile equipment in the case of outbound data received at a bts.
 figure 7 is a flow chart illustrating an embodiment of a process for bundling call data for multiple slots into a real-time transport protocol (rtp) packet. In some embodiments, the process of figure 7 is implemented at an aggregation gateway and/or bsc for outbound call data being sent to a bts via an ip network and/or at a bts for inbound call data being sent to an aggregation gateway and/or bsc via an ip network. As packet data is received, an rtp packet including slot data for at least one and up to a maximum number of slots is formed. In the example shown, the rtp packet is assembled (707) and sent (708) either as soon as call data for all (active) slots has been received (704) or a scheduled transmission time arrives (706). In some embodiments, e.g., a gsm environment, an rtp packet is transmitted every 20 msec even if call data for one or more active slots has not yet been received and cannot be included in the packet. In some embodiments, late arriving packets are dropped and not sent in a subsequent rtp packet. In other embodiments, late- arriving packets are sent in a subsequent rtp packet so long as they are not late by a period that exceeds a prescribed threshold. In the example shown, 702-708 are repeated for successive rpt packets until no further call data remains to be processed (710), after which the process ends.
 although the foregoing embodiments have been described in some detail for purposes of clarity of understanding, the invention is not limited to the details provided. There are many alternative ways of implementing the invention. The disclosed embodiments are illustrative and not restrictive.
The method of maintaining a first communication signal format active
call from a MS (mobile station) while the MS is moving between
communication systems and wherein one system is network initiated and the
other is mobile initiated and further wherein one system uses a first
communication signal format and the other uses a second communication
signal format and even further wherein a single MSC (master switching
center) controls both systems comprising, the steps of:
continuously monitoring any received radio signals from BTSs (base station
transceiver)s of both the network initiated and the mobile initiated
systems through the use of separate radio subsystems in the MS while
maintaining an active call in said first signal format;
transmitting a handover request in said first signal format in response to
a determination within said MS that said active call could be more
reliably maintained with a BTS using said second communication signal
switching the active call to said second signal format in response to a
switch command signal received from the system BTS supplying the active
call in said first communication signal format.
First of all very sorry for late reply. I was involved in major delievry of a software.
Well as far pdf file is concerned, It explains the mobile attachment procedure in GPRS setup. Whenever a mobile comes up (i.e. we switch on our mobile), then this procedure starts. In very first step MS sends it's details to BSC which includes it's TMSI, MNC, MCC, LAC, RAC. BSC further passes this details to SGSN. I hope you are well aware that in GPRS SGSN and GGSN are two new entities which make sure minimum changes in a GSM setup.
These entities further checks identity and authenticate MS details. After various checks Location update procedure starts and so the current location of MS is updated. This ends the mobile attachement procedure.
After Mobile attachement PDP context activation process starts. PDP(Packet data protocol) context is a datastructure present on both the SGSN and the GGSN which contains the subscriber's session information . When a mobile wants to use GPRS, it must first attach and then activate a PDP context. This allocates a PDP context data structure in the SGSN that the subscriber is currently visiting and the GGSN serving the subscribers access point.
I have taken the reference from eventhelix . com and wikipedia . org
I will be glad to cotinue the discussion in case of any issue.
When the phone is moving away from the area covered by call and entering the area covered by another cell, the call is transferred to the second cell in order to avoid call termination when the phone gets outside the range of the first cell
When the capacity for connecting new calls of a given cell is used up and an exixting new call from a phone, which is located in an area overlapped by another cell in order to free up some capacity in the first cell for another users, who can only be connected to the cell
In non-CDMA networks when the channel used by the phone becomes interfered by another phone using the same channel in a different cell, the call is transferred to a different channel in the same cell or to a different channel in another cell in order to avoid the interference
Again in non-CDMA networks when the user behaviour changes, e.g. when a fast-travelling user, connected to a large, umbrella-type of cell, stops then the call may be transferred to a smaller macro cell or even to a micro cell in order to free capacity on the umbrella cell for other fast-travelling users and to reduce the potential interference to other cells or users (this works in reverse too, when a user is detected to be moving faster than a certain threshold, the call can be transferred to a larger umbrella-type of cell in order to minimise the frequency of the handoffs due to this movement)
The most basic form of handover is when a phone call in progress is redirected from its current cell called source and its used channel in that cell to a new cell called target and a new channel. In terrestrial networks the source and the target cells may be served from two different cell sites or from one and the same cell site (in the latter case the two cells are usually referred to as two sectors on that cell site). Such a handover, in which the source and the target are different cells (even if they are on the same cell site) is called inter-cell handover. The purpose of inter-cell handover is to maintain the call as the subscriber is moving out of the area covered by the source cell and entering the area of the target cell.
A special case is possible, in which the source and the target are one and the same cell and only the used channel is changed during the hadover. Such a handover, in which the cell is not changed, is called intra-cell handover. The purpose of intra-cell handover is to change one channel, which may be interfered or fading with a new clearer or less fading channel.
Applying for a job can be a stressful and frustrating experience, especially for someone who has never done it before. Considering that you are competing for the position with a at least a dozen other applicants, it is imperative that you thoroughly prepare for the job interview, in order to stand a good chance of getting hired. That's where GeekInterview can help.