Call handling

with a process access request over the B interface to determine whether the subscriber is allowed to make a call. This is determined by the VLR incoming call handler which checks the state of the subscriber in the VLR.

The incoming call handler in the VLR will request the MS’ IMSI with an identity request and deny or acknowledge the request.

On an identity request, the MS sends back an identity response, containing its IMSI.

On denial, the originating MSC sends a Direct Transfer Application Part (DTAP) service reject message via the A interface, the connection to the MS is released, all resources freed and the session ended. This can happen when the MS is not present in the VLR, blocked for calling in this LAI or on a failure in the system.

On acknowledging the process access request, the originating MSC sends a DTAP service accept message back on the A interface. Then the VLR instructs the originating MSC whether it should reuse an existing TMSI or use a new TMSI.

The originating MSC now waits for a DTAP setup message from the MS. On a DTAP setup message the originating MSC makes a request info for outgoing call request to the VLR on the E interface. If the call is an emergency call the VLR rejects the call since the system does not support emergency call handling. Otherwise the VLR checks whether the requested service is supported and replies to the originating MSC with a complete call message. On a complete call message, the originating MSC requests a RTP termination, sends a DTAP call proceeding message to the MS and a BSSMAP assignment request on the A interface to allocate the voice circuit on the BSS side.

The BSS replies with a BSSMAP assignment complete to confirm. Now the originating MSC sends an ISUP Initial Address Message (IAM) message to the GMSC over the E interface. The GMSC requests the necessary information for addressing and routing the call and replies with ISUP Addressing Complete Message (ACM) if successful, and with an ISUP Release (REL) message if failed.

The GMSC then forwards an ISUP Call Progressing (CPG) message from the terminating MSC to indicate, that the terminating MS has received the call and is alerting. On the ISUP CPG message the originating MSC sends a DTAP alerting message to the MS.

On answering, the GMSC forwards the ISUP Answer Message (ANM) to the originating MSC which completes the CS context and sends a DTAP connect message to the originating MS. The MS confirms with a DTAP connect ACK, at this point the call is active.

Receiving a call

Terminating calls are handled according to [1] subsection 5.2.2. The MSC and VLR procedures used are subsets of the procedures in [4] section 7.3.

Figure 4.13: Terminating call sequence

The terminating MSC initially gets an ISUP IAM via the E interface from the GMSC. On receiving the IAM the terminating MSC sends an send info for incoming call message via the B interface to the VLR and requests a RTP termination from the termination agent.

The VLR incoming call handler routine checks the validity of the request and its parameters and replies with a page MS message or a send info for incoming call negative response back to the terminating MSC.

On a page MS message from the VLR the terminating MSC sends a BSSMAP paging message to the terminating MS, an ISUP ACM message to the GMSC and then it waits for the BSSMAP page response.

On a BSSMAP page response the terminating MSC makes a process access request to its VLR and waits for the result. The VLR checks the state of the subscriber and replies with a complete call message or a negative response.

On receiving the complete call message from the VLR the terminating MSC sends a DTAP setup via the A interface to the MS and waits for a response to the setup message.

On a DTAP call confirmed message from the terminating MS the terminating

MSC sends a BSSMAP assignment request to the BSS to establish the connec-tion between the BSS and the MS.

On successful connection establishment the MS sends a DTAP alerting message to confirm, that the terminating MS has received the call request and is alerting.

The terminating MSC sends an ISUP CPG message to the GMSC to inform the originating side about the call progressing. and waits for the MS to answer the call.

On answering the call the MS sends a DTAP connect on which the terminating MSC initiates the CS to connect the media, sends an ISUP ANM to the GMSC, a DTAP connect ACK back to the MS and a complete call ACK to the VLR.

At this point, the call is established.

Releasing a call

Releasing a call is also described in and implemented according to [1].

Figure 4.14: Example for a release sequence

All participating MSCs and MSs can release a call at any time. For that all MSC instances support ISUP REL and ISUP RLC commands at any time in the call process. On releasing the ISUP REL are forwarded to the next MSC in the call entity chain. All MSCs release their respective media resources and the O-MSC and T-MSC disconnect the connection to their respective MS.

Routing a call

When a message is sent to the transit module, routing is done based on the dialed digits and who the message originated from. The transit module does a B-number analysis in order to check if the format of the number is correct.

Then it selects a new Destination Point Code (DPC) and CIC for the outgoing connection. It sets its own point code (PC) as the Originating Point Code (OPC) and sends the message where it is supposed to be sent. There is one CIC and

PC for each connection and anything received on one pair is sent to the other pair associated with it.

IMSI origin analysis The B-Number analysis consists of IMSI origin analysis to determine the B-number Origin (BO). Here we assume the BO to be 30 which signifies it is a call originating message. The result of the IMSI origin analysis is sent to the Pre-Analysis, The Pre-Analysis calculates the (Origin for B-Number Analysis (OBA)) of the B-Number analysis.

Pre-Analysis The pre-analysis table makes use of the extra information con-tained in the setup message originating from the MS, the B-Number Type (BNT) and the Numbering Plan Identifier (NAPI). By using the extra informa-tion about the B-number, it is possible, for example to direct an internainforma-tional number directly to an Origin for B-Number Analysis (OBA) containing only numbers in the international format. Pre-analysis is used as a filtering and selection tool.

Examples (filtering)

BNT=2, B-number=0047, NAPI=0

This would be ignored since NAPI is 0 which is a reserved value.

BNT=2, B-number=0047, NAPI=1

In this case we continue in the origin specified in the table.

Examples (selection)

BNT=0, B-number=0047, NAPI=1

BNT=0 represents an unknown number and thus OBA is 30.

BNT=1, B-number=0047, NAPI=1

BNT=1 represents an international number and thus OBA is 32.

B-number analysis The analysis checks where the message is supposed to be routed by looking at the country code (CC) and national destination code (NDC).

Requesting a roaming number To be able to route a call in a GSM-network the G-MSC has to request routing information from the HLR, which in turn requests a roaming number from the VLR in which area of responsibility the called MS is currently roaming. Our system supports roaming numbers to be spec-compliant. On a request for routing information from the g_worker to the HLR stub. The HLR stub requests a roaming number from the VLR. Since the HLR is stubbed, all requests go directly to our VLR. The VLR allocates a roaming number (refer 4.15 for details on the procedure in the VLR) for the call and returns it to the HLR, which returns it back to the g_worker. The

roaming number is released by the mt_worker after the call has been finished or canceled.

Figure 4.15: The allocation process in the VLR to provide a roaming number for an incoming call