STUDY OF NETWORK NODES RELIABILITY …teca.elis.org/7178/INGALLO.pdf · STUDY OF NETWORK NODES...

STUDY OF NETWORK NODES RELIABILITY

DEVELOPMENT OF TREND ANALYSIS APPLICATIONS FOR THE NETWORK SUPPORT

By

Sebastiano Ingallo

Course tutor

Cristian D'Aloisi

Thesis advisor

Stefano Gollinucci

TELECOMMUNICATION MANAGER 7

2005 - 2007

19 February - 20 June 2007

Telecommunication Manager 7

1

Table of contents

Preface 7

1. Introduction 10

2. About Vodafone 11

2.1 History 11

3. Signaling protocols 12

3.1 Protocols 12

3.2 SS7 History 12

3.3 SS7 Functionality 13

3.4 SS7 Protocol Stack 15

3.5 INAP 16

3.6 MAP 17

3.6.1 Facilities provided 17

3.6.2 Published specifications 18

3.6.3 Implementation 18

3.7 ISUP 18

3.7.1 ISUP variants 19

3.7.2 Message types 19


2

3.8 SCCP 20

3.8.1 Published specifications 21

3.8.2 Routing facilities beyond MTP-3 21

3.8.3 Classes of service 22

4. GSM - Global System for Mobile Communications 25

4.1 Overview 25

4.2 Network Structure 26

4.3 Signaling Backbone 29

4.3.1 Voice Signaling Backbone 30

4.3.2 Signaling Backbone (third layer) 34

4.4 GSM Mobility 39

4.5 Identifiers in the GSM Network 41

4.5.1 International Mobile Subscriber Identity 41

4.5.2 MSISDN Number 42

4.5.3 International Mobile Equipment Identifier 43

4.5.4 Mobile Station Roaming Number 44

4.6 Basic services 45

4.6.1 Tele services 45

4.6.2 Bearer services 46

4.7 Supplementary services 47


3

5. GPRS - General Packet Radio Service 48

5.1 Overview 48

5.2 GPRS technical overview 49

5.2.1 SGSN 50

5.2.2 GGSN 51

5.2.3 Connectivity between the SGSN & GGSN 51

5.3 IP Addressing 53

5.3.1 Allocating addresses 53

5.3.2 How does the SGSN know which GGSN to direct you to? 54

5.3.3 IP Version 6 55

5.4 GPRS handset classes 56

5.4.1 Class A 56

5.4.2 Class B 56

5.4.3 Class C 56

5.5 GPRS QoS 57

5.5.1 Network architecture 57

5.5.2 Radio interface 57

5.5.3 Classes of GPRS services 57

5.6 Problems with GPRS 59


4

6. UMTS - Universal Mobile Telecommunication Systems 60

6.1 Definition 60

6.2 Overview 60

6.3 2G to 3G: GSM Evolution 61

6.4 UMTS Network architecture 62

6.4.1 Network elements from GSM Phase 1/2 63

6.4.2 Network elements from GSM Phase 2 + 64

6.4.3 Network elements from UMTS Phase 1 65

6.5 UMTS Interfaces 70

7. TRENDY Suite 81

7.1 Overview 81

7.1.1 Trendy Batch service 82

7.1.2 Trendy Client 84

7.2 Trendy Server 89

7.2.1 Overview 89

7.2.2 "Gestione Elenco Client" 91

7.2.3 "Gestione Apparati" 96

7.2.4 "Gestione Elenco KEY DNCP" 100

7.2.5 "Gestione Elenco KEY" 101

7.2.6 "Elenco SM" 102


5

7.2.7 "Impostazione Parametri" 103

8. SIGTRAN & EAGLE 5 109

8.1 SIGTRAN 109

8.1.1 SIGTRAN Definition and overview 109

8.1.2 Why develop a new transport protocol? 111

8.1.3 SIGTRAN Protocol architecture 112

8.1.4 SCTP 113

8.1.5 M2PA 116

8.1.6 M2UA 117

8.1.7 M3UA 117

8.1.8 SUA 118

8.2 Lucent/Tekelec EAGLE 5 119

8.2.1 Eagle 5 Network Architecture 120

8.2.2 Logical connections 120

8.2.3 Physical connections 122

Conclusions 128

Acknowledgments 125

Attachment - Trendy Server Demo Code 129


6

PrefaceMy experience with Elis starts on 3 october 2005, since first days I met cosy people who let me feel at ease.

During the course I studied various subjects, starting from computer science basics, go-ing toward some main programming languages and finishing with computer networks. Furthermore I took part in the development of two projects.

The subjects I liked better are those concerning networking, in particular Cisco CCNA and Cisco network security curricula, in fact the first one let me successfully pass the Cisco CCNA certification exam, a certification I strongly desired. Besides, for my part, the courses on UNIX operating systems and theirs security have been very interesting, since all along I'm keen about UNIX. Moreover I think that the course concerning safe programming with Visual Basic 6 has been very helpful, cause in the stage i pro-grammed with VB6.

End on first year I contributed to develop a web platform used for the management of the rooms in the Elis offices. Such a platform gives to a teacher the opportunity to reserve a room via web and it shows, in a display located in the lounge, a list with the room and the reservations. Furthermore, with the list, it is also shown a sponsor movie. My own task has been to develop the part concerning the visualization of the list and the movie.

After that project I worked with some guys that were attending a stage at Elis. The pro-ject consisted in the development of a web platform used to create, on demand, a virtual networking lab. In this case my own task has been to study in which way the XML markup language could be used to retrieve data about the lab, as an example the num-ber of PCs or routers to use.

I started the second year by staying in Dublin for five weeks. The goal of that perma-nence has been to improve my english by working and living with mother tongue people. I worked as an assistant at the UCD's Computing Center (University College of Dublin). By now I think about that experience as an amazing opportunity to improve my english


7

and to meet wonderful people, which let me feel at home and people with which I'm still keeping in touch.

Once I come back from Dublin I started to study again for the Cisco curricula, in view of the fact that I was going to take the Cisco certification exam. As I mentioned before, I'm very happy because I got certified and to this day, when I think about the certification day, 19 december, I still feel a kind of excited.

But in those days other important things were also happening, I'm talking about the in-terviews I had with Elis' partner companies, actually the first out and out interviews I ever had with external companies. I interviewed both with RAI and Ericsson. In particular the first one has been a technical interview, while the second one has been I kind of per-sonal interview. After the interviews the Ericsson's representative called me and offered me to work in Ericsson for a stage.

In the first days of January the all classroom has been involved in an amazing experi-ence, in fact Emilio Tonelli, our teacher, suggested us to use our knowledge in a scenario like the real world. The lab experience has been called "Digital War", it con-sisted in the simulation of an environment like the internet, in which we had to set up services and make them work in a safely way to hold up on attacks. We have been di-vided in five groups of three people, each group had to set up and manage their own service, further mandatory services as ftp and ssh. After set up the services, each group would attack each other trying to find and to exploit weaknesses. My group had the task to set up a blog server. After only one day of war, my group suddenly got the password of the router which connected together all servers, then I let you realize how easily we got the control of the whole network.

The days next the "Digital War" I received a proposal from Elis, they would give me the opportunity to work for a stage in the Vodafone centre of Ivrea. Then I thought that such a stage could be very helpful to improve my knowledge about mobile communications, hence, on 31 January I had an interview with my leader Stefano Gollinucci and on 19 February I started my experience in Vodafone.

I joined in a team involved in the support and management of the network and the inter-national roaming. Such a team is widespread in three facilities: Roma, Milano and Ivrea.


8

There my own task has been to contribute in the developing of a software suite used for the network monitoring.


9

1. IntroductionThe project's purpose is to study the reliability of the network and its nodes by develop-ing a group of trend analysis applications for the network support.

The main task is therefore to provide a support in the implementation of a software suite. This suite offers two services: the daily interrogation of the NFM system, for the recovery of the HTSs reports (using predetermined keys) and the direct recovery of the DNCPs reports. Such a suite includes three different applications:

Trendy Batch Service

Trendy Server

Trendy Client

These three applications will be discussed in depth in the next pages.

Anyway, when I arrived in Vodafone, the Trendy Batch Service and the Trendy Server applications were already developed and they were working properly, by then only the Trendy Server needed to be completed. Thus, to give support to a colleague in the Trendy Server development has been my own task.

In the next pages I will give you a brief history on how the former Omnitel group has be-come the actual Vodafone Italia. Successively, I will talk about different types of proto-cols involved in mobile networks and three of the most widely used mobile phones tech-nologies, or rather the three technologies currently used by Vodafone Italia. Next I will point out how the Trendy suite works and what I have done to contribute to the Trendy Server implementation.

Finally, I will give you a brief overview of the SIGTRAN technology (such a technology is going to be introduced in the Vodafone's network) and I will talk about the new EAGLE 5 devices.


10

2. About VodafoneVodafone Italia (former Omnitel Pronto- Italia) is an Italian mobile telephony operator. The company has 26,188,000 customers, as of 30 September 2006, placing it just be-hind TIM. Vodafone Italia is an owned subsidiary of Vodafone Group plc (76.86%) & Ver-izon (23.14%), and like other European operators, uses GSM and UMTS technologies.

2.1 History

Omnitel Pronto-Italia launched its services in Italy.

Omnitel was a mobile operator and Infostrada (today owned by Wind) was a fixed-line operator. They belonged to Olivetti and represented the first telephone alternative to monopolists TIM and Telecom Italia.

Original majority owner Olivetti sold its interest in Omnitel and Infostrada to the German consortium Mannesmann (which had been a minority shareholder since 1997) after Oli-vetti took control of Telecom Italia, and thus TIM, in 1999, Mannesmann took control of Omnitel with a 53.7% equity stake.

The following year Vodafone purchased Mannesmann, thus taking control of Omnitel. The Vodafone brand was introduced as Omnitel-Vodafone in 2001, made the primary brand as Vodafone-Omnitel in 2002; finally the current name Vodafone Italia was intro-duced in 2003, dropping "Omnitel" altogether. Vodafone Italia still uses the old Vodafone Speechmark logo.


11

3. Signaling Protocols

3.1 Protocols

The Vodafone Signaling Network is based on the Signaling System #7, that is a set of telephony signaling protocols which are used to set up the vast majority of the world's public switched telephone network telephone calls.

It is usually abbreviated to SS7 though in North America it is often referred to as CCSS7, an acronym for "Common Channel Signaling System 7". In some European countries, specifically the United Kingdom, it is sometimes called C7 (CCITT number 7) and is also known as number 7 and CCISTT (ITU-T was formerly known as CCITT).

3.2 SS7 History

The SS7 protocols have been developed by AT&T since 1975 and defined as standard by ITU-T during 1981 in ITU-T's Q.7XX-series recommendations. SS7 was designed to replace Signaling System #5 (SS5) and Signaling System #6 (SS6) and R2, all of which are ITU standards defined by ITU-T prior to SS7 and were once in widespread interna-tional use. SS7 has substantially replaced SS6, SS5, and R2, with the exception that R2 variants are still used in numerous nations. SS5 and earlier used in-band signaling , where the call-setup information was sent by playing special tones into the telephone lines (known as bearer channels in the parlance of the telecom industry). This led to a number of security problems when users discovered on certain telephone switching equipment that they could play these tones into the telephone handset and control the network even without the "special keys" on an operators handset. So-called phreaks experimented with fooling the telephone exchanges by sending their own user-generated signaling tones from small electronic boxes known as blue boxes. Modern


12

designs of telephone equipment that implement in-band signaling protocols explicitly keep the end-user's audio path—the so-called speech path—separate from the signaling phase to eliminate the possibility that the MF tones used for signaling are introduced by the end-user, which defeats the blue-box phreaking technique.

SS7 moved to a system in which the signaling information was out-of-band, carried in a separate signaling channel. This avoided the security problems earlier systems had, as the end user had no connection to these channels. SS6 and SS7 are referred to as so-called Common Channel Interoffice Signaling Systems (CCIS) or Common Channel Signaling (CCS) due to their hard separation of signaling and bearer channels. However it also required a separate channel dedicated solely to signaling, but due to the rapid rise in the number of available channels at the same time this was a moot point.

3.3 SS7 Functionality

Signaling refers to the exchange of information between call components required to provide and maintain service.

As users of the PSTN, we exchange signaling with network elements all the time. Exam-ples of signaling between a telephone user and the telephone network include: dialing digits, providing dial tone, accessing a voice mailbox, sending a call-waiting tone, etc.

SS7 is a means by which elements of the telephone network exchange information. In-formation is conveyed in the form of messages.

SS7 provides a universal structure for telephony network signaling, messaging, interfac-ing, and network maintenance. It deals with establishment of a call, exchanging user in-formation, call routing, different billing structures, and supports Intelligent network (IN) services.

The most fundamental use of SS7 is to deliver a telephone call across the large public switched telephone network. To do this the call must make several hops (from my phone


13

company, to a long distance company, to your local company, and so forth). At each hop along the way the telephone switches need to know from where the call is coming in (which phone line or which channel of a trunk) and to where it needs to go. This takes a lot of coordination. ISUP (or ISDN user part signaling) is a type of SS7 communication which deals with getting all these various links of the end to end call lined up. The ISUP messages get passed along from hop to hop, and at each point the the call's circuit gets extended a little further until it is built end to end.

In order to move some non-time critical functionality out of the main signaling path, and for future flexibility, the concept of a separate "service plane" was introduced by the IN technology. The initial, and still the most important use of IN technology has been for number translation services, e.g. when translating toll free numbers to regular PSTN numbers. But much more complex services have since been built on IN, such as CLASS and prepaid telephone calls.

SS7 is used in the mobile cellular telephony networks like GSM and UMTS for voice (Circuit Switched [CS Below]) and data (Packet Switched [PS Below]) applications.

Here are some of the GSM/UMTS CS interfaces in the MSC transported over SS7:

B -> VLR (uses MAP/B). Most MSCs are associated with a VLR, making the B interface "internal".

D -> HLR (uses MAP/D) for attaching to the CS network and location update

E -> MSC (uses MAP/E) for inter-MSC handover

F -> EIR (uses MAP/F) for equipment identity check

H -> SMS-G (uses MAP/H) for SMS over CS

There are also several GSM/UMTS PS interfaces in the SGSN transported over SS7:

Gr -> HLR for attaching to the PS network and location update

Gd -> SMS-C for SMS over PS


14

Gs -> MSC for combined CS+PS signaling over PS

Ge -> Charging for CAMEL prepaid charging

Gf -> EIR for equipment identity check

3.4 SS7 Protocol Stack

The SS7 protocol stack borrows partially from the OSI Model of a packetized digital pro-tocol stack. OSI layers 1 to 3 are provided by the Message Transfer Part (MTP) of the SS7 protocol; for circuit related signaling, such as the Telephone User Part (TUP) or the ISDN User Part (ISUP), the User Part provides layers 4 to 7, whereas for non-circuit re-lated signaling the Signaling Connection and Control Part (SCCP) provides layer 4 ca-pabilities to the SCCP user. The Transaction Capabilities Application Part (TCAP) is the primary SCCP User in the Core Network, using SCCP in connectionless mode. SCCP in connection oriented mode provides the transport layer for air interface protocols such as BSSAP and RANAP. TCAP provides transaction capabilities to its Users (TC-Users), such as the Mobile Application Part, the Intelligent Network Application Part and the CAMEL Application Part.

The MTP covers the transport protocols including network interface, information transfer, message handling and routing to the higher levels. SCCP is a sub-part of other L4 pro-tocols, together with MTP 3 it can be called the Network Service Part (NSP), it provides end-to-end addressing and routing, connectionless messages (UDTs), and management services for the other L4 user parts. TUP is a link-by-link signaling system used to con-nect calls. ISUP is the key user part, providing a circuit-based protocol to establish, maintain, and end the connections for calls. TCAP is used to create database queries and invoke advanced network functionality, or links to intelligent networks (INAP), mobile services (MAP), etc.

The following table summarizes the SS7 protocol suite.


15

SS7 protocol suite

Layer Protocols

ApplicationINAP, MAP, IS-41, ...

TCAP, CAP, ISUP, ...Transport SCCPNetwork MTP Level 3Data link MTP Level 2Physical MTP Level 1

Below are described some protocols that are widely used in the mobile cellular teleph-ony networks.

3.5 INAP

The Intelligent Network Application Part (INAP) is a signalling protocol used in the intelli-gent network architecture. It is part of the SS7 protocol suite, typically layered on top of TCAP.

The ITU defines several "capability levels" for this protocol, starting with Capability Set 1 (CS-1). A typical application for the IN is a Number Translation service. For example, in the United Kingdom, 0800 numbers are freephone numbers and are translated to a geo-graphic number using an IN platform. The Telephone exchanges decode the 0800 num-bers to an IN trigger and the exchange connects to the IN.

The Telephone exchange uses TCAP, SCCP and INAP and in IN terms is a Service Switching Point. It sends an INAP Initial Detection Point (IDP) message to the Service Control Point. The SCP returns an INAP Connect message, which contains a geographic number to forward the call to.


16

INAP messages are defined using ASN.1 encoding. SCCP is used for the routing. Ex-tended form of INAP is Customized Applications for Mobile Enhanced Logic. TCAP is used to separate the transactions into discrete units.

3.6 MAP

The Mobile Application Part (MAP) is an SS7 protocol which provides an application layer for the various nodes in GSM and UMTS mobile core networks and GPRS core networks to communicate with each other in order to provide services to mobile phone users. The Mobile Application Part is the application-layer protocol used to access the Home Location Register, Visitor Location Register, Mobile Switching Center, Equipment Identity Register, Authentication Centre, Short message service center and Serving GPRS Support Node.

3.6.1 Facilities provided

The primary facilities provided by MAP are:

Mobility Services: location management (when subscribers move within or be-tween networks), authentication, managing service subscription information, fault recovery,

Operation and Maintenance: subscriber tracing, retrieving a subscriber's IMSI

Call Handling: routing, managing calls whilst roaming, checking that a sub-scriber is available to receive calls

Supplementary Services

Short Message Service


17

Packet Data Protocol (PDP) services for GPRS: providing routing information for GPRS connections

Location Service Management Services: obtaining the location of subscribers

3.6.2 Published specification

The Mobile Application Part specifications were originally defined by the GSM Associa-tion, but are now controlled by ETSI/3GPP. MAP is defined by two different standards, depending upon the mobile network type:

MAP for GSM (prior to Release 4) is specified by 3GPP TS 09.02;

MAP for UMTS ("3G") and GSM (Release 99 and later) is specified by 3GPP TS 29.002.

3.6.3 Implementation

MAP is a Transaction Capabilities Application Part (TCAP) user, and as such can be transported using 'traditional' SS7 protocols or over IP using SIGTRAN via an appropriate adaptation layer such as the SCCP User Adaptation (SUA) layer or MTP3 User Adaptation (M3UA) layer.

3.7 ISUP

The ISDN User Part or ISUP is part of the Signaling System #7 which is used to set up telephone calls in Public Switched Telephone Networks. It is specified by the ITU-T as part of the Q.76x series.


18

When a telephone call is set up from one subscriber to another, many telephone ex-changes will be involved, possibly across international boundaries. To allow the call to be set up correctly, the switches signal call-related information like called or calling party number to the next switch in the network using ISUP messages.

The telephone exchanges are connected via E1 or T1 trunks which transport the speech from the calls. These trunks are divided into 64 kbit/s timeslots, and one timeslot can carry exactly one call. Each timeslot between two switches is uniquely identified by a Circuit Identification Code (CIC) which is included in the ISUP messages. The exchange uses this information along with the received signaling information (especially the Called Party Number) to determine which inbound CICs and outbound CICs should be con-nected together to provide an end to end speech path.

In addition to call related information, ISUP is also used to exchange status information of the available timeslots. In the case of no outbound CIC being available on a particular exchange, a blocking messages is sent back to the previous switch in the chain so a new route can be tried.

3.7.1 ISUP variants

Different ISUP variants exist. The main specification task is performed by the ITU-T. In Europe ETSI releases its own ISUP specification which is very close to the ITU-T ISUP. The ITU-T and ETSI ISUP are used for international connections and they are the base for national ISUP variants. Most of the countries have their own ISUP variant to cover national specific requirements. In the USA ANSI specifies the North American ISUP vari-ant which is quite different from the ITU-T ISUP.

3.7.2 Message types

After the mandatory fixed-length Signaling Information Field, an ISUP message contains a variable-length part that is dependent on the type of message being sent. These mes-


19

sages are transmitted in various stages of call setup and teardown. The most common messages are:

Initial Address Message (IAM): First message sent to inform the partner switch, that a call has to be established on the CIC contained in the message. Con-tains the called and calling number, type of service (speech or data) and many more optional parameters.

Subsequent Address Message (SAM): In case the IAM did not contain the full called number, one or more SAMs may follow containing additional digits.

Address Complete Message (ACM): Message returned from the terminating switch when the subscriber is reached and the phone starts ringing.

Answer Message (ANM): Sent when the subscriber picks up the phone. Nor-mally charging starts at this moment.

Release (REL): Sent to clear the call when a subscriber goes on hook.

Release complete (RLC); Acknowledgement of the release - the timeslot is idle afterwards and can be used again. This is also sent (without a preceding Re-lease message) if the terminating switch determines that the call cannot be com-pleted. The terminating switch also sends a Cause Value to explain the reason for the failure, e.g., "User busy".

3.8 SCCP

Signaling Connection and Control Part (SCCP) is a transport layer protocol which pro-vides extended routing, flow control, segmentation, connection-orientation, and error cor-rection facilities in Signaling System 7 telecommunications networks. SCCP relies on the services of MTP for basic routing and error detection.


20

3.8.1 Published specification

The base SCCP specification is defined by the ITU-T, in recommendations Q.711 to Q.714. There are, however, regional variations defined by local standards bodies. In the United States, ANSI publishes its modifications to Q.713 as ANSI T1.112 or JT-Q.711 to JT-Q.714, whilst in Europe ETSI publishes ETSI EN 300 009, which documents its modi-fications to the ITU-T specification.

3.8.2 Routing facilities beyond MTP-3

Although MTP-3 provides routing capabilities based upon the Point Code, SCCP allows routing using a Point Code and Subsystem number or a Global Title.

A Point Code is used to address a particular node on the network, whilst a Subsystem number addresses a specific application available on that node. SCCP employs a proc-ess called Global Title Translation (which is similar to DNS resolution in IP networks) in order to determine Point Codes from Global Titles so as to instruct MTP-3 on where to route messages.

SCCP messages contain parameters which describe the type of addressing used, and how the message should be routed:

Address Indicator:

Subsystem indicator: The address includes a Subsystem Number;

Point Code indicator: The address includes a Point Code.

Global title indicator:

No Global Title;

Global Title includes Translation Type (TT), Numbering Plan Indicator (NPI) and Type of Number (TON);


21

Global Title includes Translation Type only.

Routing indicator:

Route using Global Title only;

Route using Point Code/Subsystem number.

Address Indicator Coding:

Address Indicator coded as national (the Address Indicator is treated as international if not specified).

3.8.3 Classes of service

SCCP provides 5 classes of service to its applications:

Class 0: Basic connectionless;

Class 1: Sequenced connectionless;

Class 2: Basic connection-oriented;

Class 3: Flow control connection oriented;

Class 4: Error recovery and flow control connection oriented.

The connectionless protocol classes provide the capabilities needed to transfer one Network Service Data Unit (NSDU) in the "data" field of an XUDT, LUDT or UDT mes-sage. When one connectionless message is not sufficient to convey the user data con-tained in one NSDU, a segmenting/reassembly function for protocol classes 0 and 1 is provided. In this case, the SCCP at the originating node or in a relay node provides segmentation of the information into multiple segments prior to transfer in the "data" field


22

of XUDT (or as a network option LUDT) messages. At the destination node, the NSDU is reassembled.

The connection-oriented protocol classes (protocol classes 2 and 3) provide the means to set up signaling connections in order to exchange a number of related NSDUs. The connection-oriented protocol classes also provide a segmenting and reassembling ca-pability. If an NSDU is longer than 255 octets, it is split into multiple segments at the originating node, prior to transfer in the "data" field of DT messages. Each segment is less than or equal to 255 octets. At the destination node, the NSDU is reassembled.[1]

Class 0: Basic connectionless

The SCCP Class 0 service is the most basic of SCCP transports. Network Service Data Units passed by higher layers to the SCCP in the originating node are delivered by the SCCP to higher layers in the destination node. They are transferred independently of each other. Therefore, they may be delivered to the SCCP user out-of-sequence. Thus, this protocol class corresponds to a pure connectionless network service. As a connec-tionless protocol, no transport-level dialog is established between the sender and the re-ceiver.

Class 1: Sequenced connectionless

SCCP Class 1 builds on the capabilities of Class 0, with the addition of a sequence con-trol parameter in the NSDU which allows the SCCP User to instruct the SCCP that a given stream of messages should be delivered in sequence. Therefore, Protocol Class 1 corresponds to an enhanced connectionless service with in-sequence delivery.

Class 2: Basic connection-oriented

SCCP Class 2 provides the facilities of Class 1, but also allows for an entity to establish a two-way dialog with another entity using SCCP.


23

Class 3: Flow control connection oriented

Class 3 service builds upon Class 2, but also allows for expedited (urgent) messages to be sent and received, and for errors in sequencing (segment re-assembly) to be de-tected and for SCCP to restart a connection should this occur.

Class 4: Error recovery and flow control connection oriented

Whilst SCCP Class 3 allows for error detection, Class 4 supports re-transmitting mes-sages when errors occur.


24

4. GSM - Global System for Mobile Communications

4.1 Overview

The Global System for Mobile communications (GSM: originally from Groupe Spécial Mobile) is the most popular standard for mobile phones in the world. GSM service is used by over 2 billion people across more than 212 countries and territories.

The ubiquity of the GSM standard makes international roaming very common between mobile phone operators, enabling subscribers to use their phones in many parts of the world.

GSM differs significantly from its predecessors in that both signaling and speech chan-nels are Digital Call quality, which means that it is considered a second generation (2G) mobile phone system. This fact has also meant that data communication was built into the system from the 3rd Generation Partnership Project (3GPP).

From the point of view of the consumers, the key advantage of GSM systems has been higher digital voice quality and low cost alternatives to making calls such as text mes-saging.

The advantage for network operators has been the ability to deploy equipment from dif-ferent vendors because the open standard allows easy inter-operability. Like other cellu-lar standards GSM allows network operators to offer roaming services which mean sub-scribers can use their phones all over the world.

As the GSM standard continued to develop, it retained backward compatibility with the original GSM phones; for example, packet data capabilities were added in the Release


25

‘97 version of the standard, by means of GPRS. Higher speed data transmission has also been introduced with EDGE in the Release '99 version of the standard.

4.2 Network structure

The following picture is a schematic overview of the main components in a GSM net-work. The various interface labels are the formal names given to these interfaces.

The GSM network consists mainly of the following functional parts:

MSC – the mobile service switching centre (MSC) is the core switching entity in the network. The MSC is connected to the radio access network (RAN); the RAN is formed by the BSCs and BTSs within the Public Land Mobile Network (PLMN). Users of the GSM network are registered with an MSC; all calls to and from the


26

user are controlled by the MSC. A GSM network has one or more MSCs, geo-graphically distributed.

The Vodafone's network has roughly 80 MSCs.

VLR – the visitor location register (VLR) contains subscriber data for subscrib-ers registered in an MSC. Every MSC contains a VLR. Although MSC and VLR are individually addressable, they are always contained in one integrated node.

GMSC – the gateway MSC (GMSC) is the switching entity that controls mobile terminating calls. When a call is established towards a GSM subscriber, a GMSC contacts the HLR of that subscriber, to obtain the address of the MSC where that subscriber is currently registered. That MSC address is used to route the call to that subscriber.

HLR – the home location register (HLR) is the database that contains a sub-scription record for each subscriber of the network. A GSM subscriber is normally associated with one particular HLR. The HLR is responsible for the sending of sub-scription data to the VLR (during registration) or GMSC (during mobile terminating call handling).

CN – the core network (CN) consists of, amongst other things, MSC(s), GMSC(s) and HLR(s). These entities are the main components for call handling and subscriber management. Other main entities in the CN are the equipment iden-tification register (EIR) and authentication centre (AUC).

The Vodafone's Backbone (core network) is composed of 12 HTSs (Hub Transit Switch-ing), each HTS has the task to carry traffic related to voice and SMS. The core network is separated in four different zones: Milano, Bologna, Roma and Napoli; each zone in-cludes three HTS and every MSC is connected to the HTS of its own zone. All the HTSs are connected in a three layer topology, each layer includes four HTSs and it is con-nected one each other. The first two layers are used for voice transport, whereas the third and last layer is used for SMS signaling transport.


27

BSS – the base station system (BSS) is composed of one or more base station controllers (BSC) and one or more base transceiver stations (BTS). The BTS con-tains one or more transceivers (TRX). The TRX is responsible for radio signal transmission and reception. BTS and BSC are connected through the Abis inter-face. The BSS is connected to the MSC through the A interface.

MS – the mobile station (MS) is the GSM handset.

A GSM network is a public land mobile network (PLMN). Other types of PLMN are the time division multiple access (TDMA) network or code division multiple access (CDMA) net-work. GSM uses the following sub-division of the PLMN:

Home PLMN (HPLMN) – the HPLMN is the GSM network that a GSM user is a subscriber of. That implies that GSM user’s subscription data resides in the HLR in that PLMN. The HLR may transfer the subscription data to a VLR (during regis-tration in a PLMN) or a GMSC (during mobile terminating call handling). The HPLMN may also contain various service nodes, such as a short message service centre (SMSC), service control point (SCP), etc.

Visited PLMN (VPLMN) – the VPLMN is the GSM network where a subscriber is currently registered. The subscriber may be registered in her HPLMN or in an-other PLMN. In the latter case, the subscriber is outbound roaming (from HPLMN’s perspective) and inbound roaming (from VPLMN’s perspective). When the sub-scriber is currently registered in her HPLMN, then the HPLMN is at the same time VPLMN.

Interrogating PLMN (IPLMN) – the IPLMN is the PLMN containing the GMSC that handles mobile terminating (MT) calls. MT calls are always handled by a GMSC in the PLMN, regardless of the origin of the call. For most operators, MT call handling is done by a GMSC in the HPLMN; in that case, the HPLMN is at the same time IPLMN. This implies that calls destined for a GSM subscriber are always routed to the HPLMN of that GSM subscriber. Once the call has arrived in the HPLMN, the HPLMN acts as IPLMN. MT call handling will be described in more de-


28

tail in subsequent sections. When basic optimal routing (BOR) is applied, the IPLMN is not the same PLMN as the HPLMN.

The user of a GSM network is referred to as the served subscriber; the MSC that is serv-ing that subscriber is known as the serving MSC. Examples are:

mobile originated call – the MSC that is handling the call is the serving MSC for this call; the calling subscriber is the served subscriber;

mobile terminated call – the GMSC that is handling the call is the serving GMSC for this call; the called subscriber is the served subscriber.

4.3 Signaling Network Architecture

Each Zone is provided with:

3 Lucent 5ESS switches (HTS), each one with 3 Signaling Points addressable with different Signaling Point Codes;

1 Cisco IPTransfer Point (SGW), acting as Signaling Gateway between legacy SS7 network and SIGTRAN enabled nodes.

The first two HTS of each Zone (MIHTS01, MIHTS02, BOHTS01, BOHTS02 RMHTS01, RMHTS02, NAHTS01 and NAHTS02) are used to manage Mobility related SCCP, SMS related SCCP and ISUP signaling, while the third HTS of each Zone (MIHTS03, BOHTS03, RMHTS03 and NAHTS03) is used only to manage ISUP and SMS related SCCP signaling. The SGW of each Zone is used only to manage SCCP signaling traffic related to “Chiamami” and “Richiamami” services.


29

4.3.1 Voice Signaling Backbone

The Voice Signaling Backbone is made of the first two Signaling Point Codes of the HTS01 and HTS02 of each Zone. These 16 Signaling Point Codes are fully meshed in order to:

provide the necessary capacity required to transfer Signaling messages be-tween Zones;

provide a high reliability in case of SDH failures on the Backbone;

In the following picture it is shown the connection of a “model” HTS (in this case MIHTS01) towards a remote Zone’s HTS (in this case Zone 2).

The Link Sets defined between MIHTS11 and the 4 Signaling Points of HTSs in Bologna are shown. A Link Set of 1 High Speed Signaling Link (HSSL) is built between two Signaling Points. MIHTS12 has similar Link Sets. MIHTS02 is not shown in Figure 1, anyway MIHTS21 and MIHTS22 have identical Link Sets.

The described connections are identical to those with HTSs in Roma and in Napoli.


30

In the following picture it is shown an example of the connection that have to be config-ured between an HTS (in this case MIHTS01) and its twin HTS (in this case MIHTS02). The same configuration applies to every HTS.

Logical connectivity between MIHTS01 and MIHTS02 is realized by means of 2 Link Sets made of 2 HSSL each.

High Speed Signaling Link

High Speed Signalling Link (HSSL) functionality allows to use the whole E1 physical link (not channelized) as a single signalling link, with a bandwidth of 1984 kbit/s.

On Lucent HTS this feature will be hosted in the new Packet Handler 33 (PH33). A PH33 can handle up to two HSSL. In order to avoid that a failure of a PH33 involves the simul-taneous unavailability of two Link Sets towards the same remote Zone as well as the unavailability of two routes within a route set towards a remote Zone’s DPC, it is manda-tory that a PH33 handles HSSL towards two HTS Signaling Point Codes belonging to two different remote Zones (e.g. on MIHTS11 HSSL towards BOHTS11 and RMHTS12).

Physical Connectivity

In the following the basic principles regarding Backbone connections are described.


31

Link Sets connecting Signaling Points of HTSs belonging to two different Zones

Each of these Link Sets will be made of a single HSSL. An E1 (VC12) link will be used for a single HSSL.

In order to avoid that a failure on transmission network involves the simultaneous un-availability of two Link Sets towards the same remote Zone as well as the unavailability of two routes within a route set towards a remote Zone’s DPC on each HTS, HSSL to-wards remote Zone HTS will be mapped either on SDH interfaces (VC12 links - PLTU) or on PDH interfaces (E1 - DLTU).

In particular, on each HTS HSSL towards all remote HTS01 Signaling Points (HTS11, HTS12) will be mapped on SDH interfaces (PLTU), connected to the main local SDH cross-connect (local MSH80 DXC), while HSSL towards all remote HTS02 Signaling Points (HTS21, HTS22) will be mapped on PDH interfaces (DLTU) which will be con-nected to a different local cross-connect (local MSH41c DXC). HSSL mapped on PDH interfaces will be transported on a different transmission layer with respect to HSSL mapped on SDH interfaces.

The only exception to this rule is on NAHTS01 which is not equipped with E1 interfaces. On this NE all HSSL will be mapped on SDH interfaces (PLTU).

Link Sets connecting Signaling Points of HTSs on belonging to the same Zone

Each of these Link Sets will be made of two HSSL. HSSL belonging to the same Link Set will have complete transmission path diversity. It follows that, inside a Link Set, a HSSL will be mapped on a SDH interface (PLTU) while the other HSSL will be mapped on a PDH interface (DLTU).

Principles regarding local connections from a Site (MSCs, TSCs, HLRs, SCPs) to the couple of HTSs of the same Zone

Since between each remote site and the relevant Backbone sites there are generally only two physical SDH connections on which all PCM Links are mapped, if one SDH connection fails one half of the Signaling capacity towards the backbone will be lost. By


32

concentrating the Signaling Links on a limited number of PCMs with higher recovery pri-ority, the probability of recovering almost the complete Signaling capacity in a short time is increased. Anyway it has to be considered the case of temporary unavailability of E1 ports/units (for maintenance …) as well: thus more than one PCM must be used to carry Signaling Links of each relation.

Then the number of PCMs used to carry Signaling between an MSC/TSC and a single HTS will be 2 (let’s call them PCM-A and PCM-B).

the Signaling Links for the relation between an MSC/TSC and an HTS Signaling Point will be equally shared on PCM-A and PCM-B

one half of the Signaling Links (e.g. 2 out of 4) for the relation between an HLR/NOKIA SCP and an HTS Signaling Point will be equally shared on the same PCM-A (e.g. 1 time slot) and PCM-B (e.g. 1 time slot) connecting that MSC/TSC to the HTS; the other half will be similarly mapped on two PCMs connecting another co-located MSC/TSC to the same HTS.

The spare capacity of the abovementioned PCM Links will be filled with voice channels.

Signaling links between HLRs, SCPs, SRNs and HTSs are mapped on the TDM signaling network (SXC transport network).

By October 2004 HSSL based linksets will be introduced between some MSC/HLR and the Voice Signaling Backbone. In particular, a MSC/HLR will be connected to the Voice Signaling Backbone by means of 4 linksets (between the NE and HTS11, HTS12, HTS21, HTS22 of the same Zone) made up of a single HSSL. Each HSSL will be mapped on a E1 physical link (not channelized).


33

4.3.2 Signaling Backbone (Third layer)

SMS related signaling traffic is managed by a separate backbone layer (Third layer). Nowadays the third layer is made up of two Signaling Points for each Zone (HTS13 and HTS23) used as STP/SCCP Relay nodes.

By November 2003 a third Signaling Point for each Zone will be added (MIHTS33, BOHTS33, RMHTS33 and NAHTS33), in order to cope with the big amount of SMS re-lated signaling traffic that is expected by the end of the year. The Network Elements that will be connected to Point Code 3 of the HTS3 of each Zone are listed below:

Nokia MSC/TSC

Nokia HLR

Lucent SRF for Mobile Number Portability belonging to SMS layer (SRF03/SRF04)

Lucent SCP dedicated to IN PrePaid service

Lucent SCP dedicated to Twin Sim service (BOSCP1L and NASCP1L)

Nokia MMSC (MIMMS03)

Nokia SMSC dedicated to:

SM - Mobile Originated service

Push services

SICAP/Recharging services

MMS service


34

Physical Connectivity

Both HTS13 and HTS23 (respectively GSM # 3 of HTS1 and of HTS2, which have their own Signaling Point Codes and are completely independent of the other HTS Signaling Points) are connected to HTSx3 of the other Zones, thus forming a meshed cube. A sus-penders of 2 Link Sets of 8 links each connects HTS13 and HTS23 in the same city.

The introduction of HTS33 (GSM # 3 of HTS3, which has its own Signaling Point Code and is completely independent of the other HTS Signaling Points) will lead to a fully meshed framework, where each Signaling Point is connected to all HTSx3 of the other Zones. A suspender of 2 Link Sets of 8 links each will connect the three HTSx3 in the same Zone.

E.g. MIHTS13 has 2 Link Sets of 8 links each towards BOHTS13, 2 Link Sets of 8 links towards BOHTS23 and 2 Link Sets of 8 links each towards BOHTS33, thus between to 2 Zones the total number of Signaling Links belonging to the third layer is 144 (e.g. the 2 Link Sets between MIHTS13 and BOHTS13 are identified in the Plan, seen from MIHTS13, as BOHTS13A and BOHTS13B, while the Combined Link Set formed by them is BO1C3A3B). 2 2Mbit/s are needed between MIHTS01 and BOHTS01 in order to carry the 2 Link Sets between MIHTS13 and BOHTS13 (4 links out of 8 belonging to each Link Set are mapped on each 2Mbit/s). 2 2Mbit/s are needed between MIHTS01 and BOHTS02 in order to carry the 2 Link Sets between MIHTS13 and BOHTS23 (4 links out of 8 belonging to each Link Set will be mapped on each 2Mbit/s). 2 2Mbit/s are needed between MIHTS01 and BOHTS03 in order to carry the 2 Link Sets between MIHTS13 and BOHTS33 (4 links out of 8 belonging to each Link Set will be mapped on each 2Mbit/s). If Link Set from MIHTS13 towards BOHTS13 and BOHTS23 are mapped on the same SDH facility without diversity (e.g. a single SDH facility between sites 1 in Milan and Bologna), the suspender between the two sites in Milan needs diversity of path with the abovementioned SDH facility. The suspender between MIHTS13 and MIHTS23, between MIHTS13 and MIHTS33, between MIHTS23 and MIHTS33 are made of 2 2Mbit/s, each carrying 4 links out of 8 for each Link Set that connects the 2 Signaling Points.


35

The following picture shows the SMS signaling backbone.

By now the LSL connections between the inter-zone HTS Signaling Point of the SMS Layer has been replaced with HSSL. This architectural upgrade has the purpose of im-proving the signaling transmission capability of the SMS backbone and is part of a wider SMS Signaling Network evolution (which involves also peripherical Network Elements and connections) aimed to hold up to signaling traffic peaks due to the increasing SMS traffic.

In the following there are the details of the new architectural configuration.

Link Sets connecting Signaling Points of HTS_SMS belonging to different Zones

In the following picture it is shown the connection of HTS_SMS in a certain zone (in this case Zone 1) towards a remote Zone’s HTS (in this case Zone 3).


36

In particular it is shown that the Link Sets inter-zone will make up of:

2 HSSL between “pairs” (i.e. link sets 13-13, 23-23, 33-33);

else 1 HSSL.

The same configuration applies to connections from and towards the HTSs in the other Zones, so the total number of operative HSSL between the HTS_SMS Signaling Point is 72.

The new configuration for the SMS Backbone requires the introduction of new PH33 on Lucent HTS to replace the PH22. A PH33 can handle up to two HSSL.

As it happens for the Voice Layer Backbone interconnections, in order to avoid that a failure of a PH33 involves the simultaneous unavailability of two link set towards the same remote Zone as well as the unavailability of two routes within a route set towards a remote Zone’s DPC, it is mandatory that a PH33 handles HSSL towards two HTS Signaling Point Codes belonging to two different remote Zones (e.g. on MIHTS13 HSSL towards BOHTS13 and RMHTS13).

RMHTS33MIHTS33

MIHTS13

MIHTS23

MIHTS01

MIHTS02

MIHTS03

2 HSSL RMHTS13

RMHTS23

RMHTS02

RMHTS03

RMHTS01

2 HSSL

2 HSSL

1 HSSL

1 HSSL

1 HSSL

1 HSSL

1 HSSL

1 HSSL


37

Moreover, to improve resilience to transmission network faults, also for HSSLs for SMS Backbone is implemented a transmission path diversity: HSSL towards remote Zone HTS will be mapped either on SDH interfaces (VC12 links - PLTU) or on PDH interfaces (E1 - DLTU), and HSSL mapped on PDH interfaces will be transported on a different transmission layer with respect to HSSL mapped on SDH interfaces.

For each site, the PLTU interface will be connected to the main local SDH cross-connect (local MSH80 DXC), while the DLTU interface will be connected to a different local cross-connect (local MSH41c DXC).

For detail related to the transmission configuration, make reference to the following pic-ture, considering that the relations represented are oriented and valid also for the follow-ing couples:

MI RM, MI BO, RM BO, NA MI, NA BO, NA RM.

In particular:

The blue path will be mapped on PLTU interfaces at HTS01 and HTS03 and on DLTU interface at HTS02;

The red path will be mapped on DLTU interface at HTS01 and HTS03 and on PLTU interface at HTS02.

Different trans-mission paths

RMHTS33MIHTS33

MIHTS13

MIHTS23

MIHTS02

MIHTS03

RMHTS13

RMHTS23

RMHTS02

RMHTS03

RMHTS01MIHTS01


38

These rules are applicable with the exceptions that:

At NA1b site (NAHTS01) only PLTU interface is available, and connected to DXC-MSH80;

At RM4 site (RMHTS03) the Blue path will be mapped on DLTU interface and the Red path on PLTU interface.

Link Sets connecting Signaling Points of HTS_SMS belonging to the same Zone

Intra-zone links are used as backup routes from/to periphery. About SMS Signaling layer, no HSSL towards periphery are currently in place. So, HSSL are not required for intra-zone backbone connections which remain unchanged at the configuration below repre-sented:

MIHTS13 MIHTS23 MIHTS33

16 s.l.

16 s.l. 16 s.l.

4.4 GSM Mobility

Roaming with GSM is made possible through the separation of switching capability and subscription data. A GSM subscriber has her subscription data, including CAMEL data, permanently registered in the HLR in her HPLMN. The GSM operator is responsible for provisioning this data in the HLR.

The MSC and GMSC in a PLMN, on the other hand, are not specific for one subscriber group. The switching capability of the MSC in a PLMN may be used by that PLMN’s own subscribers, but also by inbound roaming subscribers; see the next picture.


39

The GSM user who is a subscriber of PLMN-A roams to PLMN-B. The HLR in PLMN-A transfers the user’s subscription data to the MSC in PLMN-B. The subscriber’s subscrip-tion data remains in the MSC/VLR as long as she is served by a BSS that is connected to that MSC. Even when the user switches her MS off and then on again, the subscrip-tion data remains in the MSC. After an extended period of the MS being switched off, the subscription data will be purged from the MSC. When the subscriber switches her MS on again, the subscriber has to re-register with the MSC, which entails the MSC asking the HLR in the HPLMN to re-send the subscription data for that subscriber.

When the subscriber moves from one MSC service area (MSC-1) to another MSC serv-ice area (MSC-2), the HLR will instruct MSC-1 to purge the subscription data of this sub-scriber and will send the subscription data to MSC-2.


40

4.5 Identifiers in the GSM Network

GSM uses several identifiers for the routing of calls, identifying subscribers (e.g. for charging), locating the HLR, identifying equipment, etc.

4.5.1 International Mobile Subscriber Identity (IMSI)

The international mobile subscriber identity (IMSI) is embedded on the SIM card and is used to identify a subscriber. The IMSI is also contained in the subscription data in the HLR. The following picture shows its structure:

The IMSI is used for identifying a subscriber for various processes in the GSM network. Some of these are:

location update – when attaching to a network, the MS reports the IMSI to the MSC, which uses the IMSI to derive the global title (GT) of the HLR associated with the subscriber;

terminating call – when the GSM network handles a call to a GSM subscriber, the HLR uses the IMSI to identify the subscriber in the MSC/VLR, to start a process for delivering the call to that subscriber in that MSC/VLR.


41

roaming charging – a VPLMN uses the IMSI to send billing records to the HPLMN of a subscriber.

mobile country code (MCC) – the MCC identifies the country for mobile net-works. The MCC is not used for call establishment. The usage of MCC is defined in ITU-T E.212 [129]. The MCC values are allocated and published by the ITU-T.

mobile network code (MNC) – the MNC identifies the mobile network within a mobile country (as identified by MCC). MCC and MNC together identify a PLMN. Refer to ITU-T E.212 [129] for MNC usage. The MNC may be two or three digits in length. Common practice is that, within a country (as identified by MCC), all MNCs are either two or three digits.

mobile subscriber identification number (MSIN) – the MSIN is the subscriber identifier within a PLMN.

4.5.2 Mobile Station Integrated Services Digital Network Number (MSISDN Number)

The MSISDN is used to identify the subscriber when, among other things, establishing a call to that subscriber or sending an SMS to that subscriber. Hence, the MSISDN is used for routing purposes. The following picture shows its structure:


42

The MSISDN structure consist of:

country code (CC) – the CC identifies the country or group of countries of the subscriber;

national destination code (NDC) – each PLMN in a country has one or more NDCs allocated to it; the NDC may be used to route a call to the appropriate net-work;

subscriber number (SN) – the SN identifies the subscriber within the number plan of a PLMN.

The MSISDN is not stored on the subscriber’s SIM card and is normally not available in the MS. The MSISDN is provisioned in the HLR, as part of the subscriber’s profile, and is sent to MSC during registration. The MSISDN is also reported to SCP when a CAMEL service is invoked.

One subscriber may have multiple MSISDNs. These MSISDNs are provisioned in the HLR. At any one moment, only a single MSISDN is available in the MSC/VLR for the subscriber.

4.5.3 International Mobile Equipment Identifier (IMEI)

The international mobile equipment identifier (IMEI) is used to identify the ME [or user equipment (UE) in UMTS network]. Each ME has a unique IMEI. The IMEI is hard-coded in the ME and cannot be modified.

The IMEI is not used for routing or subscriber identification.


43

4.5.4 Mobile Station Roaming Number (MSRN)

The mobile station roaming number (MSRN) is used in the GSM network for routing a call to a MS. The need for the MSRN stems from the fact that the MSISDN identifies a subscriber, but not the current location of that subscriber in a telecommunications net-work. The MSRN is allocated to a subscriber during MT call handling and is released when the call to that subscriber is established.

Each MSC in a PLMN has a (limited) range of MSRNs allocated to it. An MSRN may be allocated to any subscriber registered in that MSC. The MSRN has the form of an E.164 number and can be used by the GMSC for establishing a call to a GSM subscriber. An MSRN is part of a GSM operator’s number plan. The MSRN indicates the GSM network a subscriber is registered in, but not the GSM network the subscriber belongs to. The following picture shows how the MSRN is used for call routing:

The MSRN is not meant for call initiation. GSM operators may configure their MSC such that subscribers cannot dial numbers that fall within the MSRN range of that operator.


44

4.6 Basic services

All activities that may be done in the GSM network, such as establishing a voice call, es-tablishing a data call, sending a short message, etc., are classified as basic services. In order for a subscriber to use a GSM basic service, she must have a subscription to that service.

The handling of a basic service is fully standardized. Hence, a subscriber may use a ba-sic service in any GSM network she roams to, provided that that basic service is sup-ported in that network. The HLR will send a list of subscribed basic services to the MSC/VLR, during registration. When a GSM subscriber initiates a call, the MS supplies the serving MSC with a set of parameters describing the circuit-switched connection that is requested.

These parameters are the bearer capability (BC), low-layer compatibility (LLC) and high-layer compatibility (HLC), as will be described below. The MSC uses the BC, LLC and HLC to derive the basic service for this call. The rules for deriving the basic service from LLC, HLC and BC are specified in GSM TS 09.07 [55]. The MSC then checks whether the subscriber has a subscription to the requested basic service, i.e. whether the sub-scription data in the VLR contains that basic service.

If the service is not subscribed to, then the MSC disallows the call. The basic service is not transported over ISUP.

Basic services are divided into two groups: tele services and bearer services.

4.6.1 Tele services

The following table provides an overview of the available tele services (TS).


45

Tele service Description Comment

11 Telephony This TS represents the normal speech call

12 Emergency calls The emergency call uses the charac-teristics of telephony (TS11), but

may be established without subscrip-tion and bypasses various checks in

the MS and in the MSC

21 Short Message MT This TS relates to receiving an SMS. This TS is not sent to the MSC/VLR.

When an SMS is sent to the sub-scriber, the HLR checks whether the destination subscriber has a subscrip-

tion to TS 21

22 Short Message MO This TS relates to the sending of an SMS

23 Cell broadcast This TS relates to the capability of an SMS that is sent as a broadcast

SMS

61 Alternate speech and fax group 3

This TS relates to the capability to establish a speech and fax (group 3)

call

62 Automatic fax group 3 This TS relates to the capability to establish a fax (group 3) call

91 Voice group call This TS relates to the capability to participate in a group call as speci-

fied in GSM TS 03.68 [35]

92 Voice broadcast This TS relates to the capability to receive a voice broadcast as speci-

fied in GSM TS 03.68 [35]

4.6.2 Bearer services

The following table provides an overview of the available bearer services (BS).


46

The two bearer service groups are sub-divided into a variety of bearer services with dif-ferent characteristics.

Bearer service Description Comment

20 Asynchronous data bearer services

May be used for asynchronous serv-ices from 300 bit/s to 64 kbit/s.

30 Synchronous data bearer services

May be used for synchronous serv-ices from 1.2 to 64 kbit/s. This BS may be used, amongst other things,

for multimedia services such as video telephony.

4.7 Supplementary services

Supplementary services (SS) in GSM are a means of enriching the user experience. An SS may, for example, forward a call in the case of no reply from the called party, bar cer-tain outgoing or incoming calls, show the number of the calling party to the called party, etc. In order to use an SS, a GSM user needs a subscription to that SS. The subscription to supplementary services is contained in the HLR and is sent to the MSC/VLR during registration. The supplementary services are fully standardized. A GSM subscriber can therefore use her supplementary services in any GSM network, provided that the net-work supports these supplementary services, and have the same user experience.

Supplementary services may be provisioned for an individual basic service or for a group of basic services, e.g. a subscriber may have barring of all outgoing calls for all tele services and all bearer services, except SMS (tele service group 20). Such a subscriber is barred from establishing outgoing calls (except emergency calls), but may still send short messages. Some supplementary services may be activated or deactivated by the user. Examples include call forwarding and call barring. An operator may decide to bar certain subscribers or subscriber groups from modifying their supplementary services.


47

5. GPRS - General Packet Radio Service

5.1 Overview

GPRS (General Packet Radio Service) is a packet based communication service for mobile devices that allows data to be sent and received across a mobile telephone net-work. GPRS is a step towards 3G and is often referred to as 2.5G. Here are some key benefits of GPRS:

Speed

GPRS is packet switched. Higher connection speeds are attainable at around 56–118 kbps, a vast improvement on circuit switched networks of 9.6 kbps. By combining stan-dard GSM time slots theoretical speeds of 171.2 kbps are attainable. However in the very short term, speeds of 20-50 kbps are more realistic.

Always on connectivity

GPRS is an always-on service. There is no need to dial up like you have to on a home PC for instance. This feature is not unique to GPRS but is an important standard that will no doubt be a key feature for migration to 3G. It makes services instantaneously avail-able to a device.

New and Better applications

Due to its high-speed connection and always-on connectivity GPRS enables full Internet applications and services such as video conferencing straight to your desktop or mobile device. Users are able to explore the Internet or their own corporate networks more effi-ciently than they could when using GSM. There is often no need to redevelop existing applications.


48

GSM operator Costs

GSM network providers do not have to start from scratch to deploy GPRS. GPRS is an upgrade to the existing network that sits along side the GSM network. This makes it eas-ier to deploy, there is little or no downtime of the existing GSM network whilst implemen-tation takes place, most updates are software so they can be administered remotely and it allows GSM providers to add value to their business at relatively small costs.

The GSM network still provides voice and the GPRS network handles data, because of this voice and data can be sent and received at the same time.

5.2 GPRS technical overview

As mentioned earlier GPRS is not a completely separate network to GSM. Many of the devices such as the base transceiver stations and base transceiver station controllers are still used. Often devices need to be upgraded be it software, hardware or both. When deploying GPRS many of the software changes can be made remotely.


49

There are however two new functional elements which play a major role in how GPRS works. The Serving GPRS Support Node (SGSN) and the Gateway GPRS support node (GGSN). These 2 nodes are new to the network with the other changes being small if any.

Before explaining what these 2 new members of our network do it is important to ask how does the network differentiate between GSM (circuit) and GPRS (packet)?

In simple terms there are in practice two different networks working in parallel, GSM and GPRS. In any GSM network there will be several BSC’s (Base Station Controllers). When implementing GPRS a software and hardware upgrade of this unit is required. The hardware upgrade consists of adding a Packet Control Unit (PCU). This extra piece of hardware differentiates data destined for the standard GSM network or Circuit Switched Data and data destined for the GPRS network or Packet Switched Data. In some cases a PCU can be a separate entity.

From the upgraded BSC there is a fast frame relay connection that connects directly to the newly introduced SGSN.

5.2.1 SGSN

The Serving GPRS Support Node, or SGSN for short, takes care of some important tasks, including routing, handover and IP address assignment.

The SGSN has a logical connection to the GPRS device. As an example, if you where in a car travelling up the M1 on a long journey and were browsing the Internet on a GPRS device, you will pass through many different cells. One job of the SGSN is to make sure the connection is not interrupted as you make your journey passing from cell to cell. The SGSN works out which BSC to “route” your connection through.

If the user moves into a segment of the network that is managed by a different SGSN it will perform a handoff of to the new SGSN, this is done extremely quickly and generally the user will not notice this has happened. Any packets that are lost during this process


50

are retransmitted. The SGSN converts mobile data into IP and is connected to the GGSN via a Tunneling protocol.

5.2.2 GGSN

The Gateway GPRS Support Node is the “last port of call” in the GPRS network before a connection between an ISP or corporate network’s router occurs. The GGSN is basically a gateway, router and firewall rolled into one. It also confirms user details with RADIUS servers for security, which are usually situated in the IP network and outside of the GPRS network.

5.2.3 Connectivity between SGSN & GGSN

The connection between the two GPRS Support Nodes is made with a protocol called GPRS Tunneling Protocol (GTP).

GPRS Tunneling Protocol is the defining IP protocol of the GPRS core network. Primarily it is the protocol which allows end users of a GSM or WCDMA network to move from place to place whilst continuing to connect to the internet as if from one location at the Gateway GPRS Support Node (GGSN). It does this by carrying the subscriber's data from the subscriber's current Serving GPRS Support Node (SGSN) to the GGSN which is handling the subscriber's session. Three forms of GTP are used by the GPRS core network.

GTP-U: for transfer of user data in separated tunnels for each PDP context, the PDP (Packet Data Protocol, e.g. IP, X.25, FrameRelay) context is a data struc-ture present on both the SGSN and the GGSN which contains the subscriber's ses-sion information when the subscriber has an active session;


51

GTP-C: for control reasons including:

Setup and deletion of PDP contexts;

Verification of GSN reach-ability;

Updates, e.g. as subscribers move from one SGSN to another.

GTP' : for transfer of charging data from GSNs to the charging function.

GGSNs and SGSNs (collectively known as GSNs) listen for GTP-C messages on UDP port 2123 and for GTP-U messages on port 2152. This communication happens within a single network or may, in the case of international roaming, happen internationally, probably across a GPRS Roaming Exchange (GRX).

The "Charging Gateway Function" (CGF) listens to GTP' messages sent from the GSNs on UDP port 3386. The core network sends charging information to the CGF, typically including PDP context activation times and the quantity of data which the end user has transferred. However, this communication which occurs within one network is less stan-dardized and may, depending on the vendor and configuration options, use proprietary encoding or even an entirely proprietary system.

GPRS is billed on per megabyte basis unlike GSM. In practice the two GSN devices may be a single unit.


52

5.3 IP Addressing

5.3.1 Allocating addresses

There are 3 different ways in which a device can be assigned an IP address.

Fixed IP addressing

Fixed IP addresses for mobile devices are not widely used due to shortages of Ipv4 ad-dresses. This information is stored in the HLR.

Dynamic IP addressing

The second means of addressing is dynamic addressing. This is where a mobile device does not have its own IP address stored in the HLR. Instead the IP address is assigned to the GGSN domain.


53

The third method is also a type of dynamic IP addressing in which the IP address is as-signed by RADIUS servers normally situated inside an IP network outside the mobile network, an example of this being when you dial up to an ISP from your home PC.

5.3.2 How does the SGSN know which GGSN to direct to you?

A mobile device is programmed with one or more Access Point Names which are com-monly referred to as the APN’s. An APN consists of a fully qualified DNS name e.g. web.omnitel.it.

When a GPRS device wants to talk to web.omnitel.it’s network, the SGSN does a DNS lookup and resolves the name to the correct GGSN. You could have multiple APN’s pro-grammed into your phone so you are not limited to a single service or GGSN.


54

5.3.3 IP Version 6

This new version of IP corrects unanticipated Ipv4 design issues that have come about because of the popularity of the Internet. In short we are running out of addresses.

IP version 4 is a 32-bit address that allows a maximum of around 4 billion IP addresses. It is estimated that by 2005 all the addresses in IP 4 will run out. Some say this will hap-pen sooner - introduce millions of handheld devices all requiring IP addresses and sud-denly there are none left.

To truly enable the Internet to such devices there has to be more addresses. This is where IP version 6 comes in. Instead of a 32-bit address, IP6 is 128 bit with a maximum number of:

340,232,366,920,938,463,463,374,607,431,768,211,456

possible IP addresses. This amount of address space is ample for future foreseeable growth.

At the moment there are around 1 billion addresses left for IP v 4 but many manufactur-ers of mobile devices especially in Asia are involving themselves heavily in IP v 6. This is mainly due to places like Japan having a fraction of the addresses allocated in compari-son with other places like America.


55

5.4 GPRS handset classes

GPRS devices are not as straightforward as you may think. There are in fact 3 different classes of device.

5.4.1 Class A

Class A terminals have 2 transceivers which allow them to send / receive data and voice at the same time. This class of device takes full advantage of GPRS and GSM. You can be taking a call and receiving data all at the same time.

5.4.2 Class B

Class B devices can send / receive data or voice but not both at the same time. Gener-ally if you are using GPRS and you receive a voice call you will get an option to answer the call or carry on.

5.4.3 Class C

This device only allows one means of connectivity. An example would be a GPRS PCMCIA card in a laptop.


56

5.5 GPRS QoS

Just because GPRS uses many of the components of a standard GSM network it would be foolhardy to assume that the same standards should apply. Things to be taken into ac-count include provider general network architecture, radio interface and throughput. Here are some of the key elements briefly explained.

5.5.1 Network architecture

Provider networks have to be upgraded. As mentioned earlier the GSN’s are new to the standard GSM network. If GPRS is to stand-up to customer expectations network per-formance will be vital.

5.5.2 Radio interface

The ETSI (European Telecommunications Standard Institute) has defined 3 new coding schemes for Radio Interface. When the GPRS device talks to the base station they can use 1 of the 4 schemes. The schemes are CS – 1 through CS – 3 where CS – 1 is the same as standard GSM. In simple terms CS – 1 is highly redundant but because of this is slow, 2 and 3 have less redundancy, whilst 4 has the least - removing all forward error control - but is capable of maximum throughput. If radio quality is bad then coding scheme 1 is used, as the quality improves less error control is needed.

5.5.3 Classes of GPRS services

Mobile devices can request different types of traffic to be prioritized in an attempt to give the user their desired level of connectivity.


57

There are 4 types of class:

Precedence Class

An application can be assigned a Precedence Class 1, 2 or 3. If an application has a higher precedence (1) than another (3) then its traffic will be given a higher priority.

Delay Class

Applications can request predictive delay classes which guarantee an average and 95-percentile delay. There are 4 classes, 1 being the fastest.

Reliability class

Applications can request differing levels of reliability for its data depending on its toler-ance to data loss.

Throughput Class

Applications can choose different profiles for throughput. There are 2 distinctions in class, peak and mean. Peak throughput class is used mainly for bursty transmissions with a variable in octets per second describing the throughput required for burst of speci-fied size. Mean is the average data transfer rate over a period of time measured in oc-tets per hour.

Other factors can affect QoS. Things like Radio quality, basic LAN / WAN and Internet congestion, faults on GSM and GPRS network’ etc.


58

5.6 Problems with GPRS

Although GPRS has many benefits there have been a few problems. Connection speeds until the end of last year performed badly on some networks running at around 12Kbps, a far cry from the expected. This year however there do not seem to be as many prob-lems, probably due to the fact that operators are improving due to trial and error. GPRS is after all a pretty new technology.

Another problem sometimes encountered is customer expectation. Many companies have applications running on a 10 megabyte LAN and expect the same performance from their GPRS devices. Although the connection speeds these days are pretty good it still is not as fast as ISDN or Local Area Networks. To a certain extent operators have themselves to blame for this, since in the past their marketing has tended to promote the speed aspects of 2.5 and 3G. Today, they are working hard to reduce expectation in this respect.

Earlier problems with things like mail servers not sending mail because of latency prob-lems to GPRS devices have all been pretty much eradicated through optimization pro-grams. People running Citrix Thin Client have also encountered problems with latency although a few Thin Client forums suggest that Citrix are addressing the issue.

Deployment on some networks has been slow. There still is a major UK network provider who does not offer the service.

GPRS roaming has not been implemented in many countries on a lot of networks as yet. This is where a user can use the GPRS service from any network operator. At the mo-ment although your GSM mobile will work, GPRS may not work at all. Accesses by third party application providers are having a lot of difficulty obtaining an APN from providers to offer their own GPRS services. This somewhat limits services to that provided by the GPRS operator.


59

6. UMTS - Universal Mobile Telecommunications System6.1 Definition

Universal Mobile Telecommunications System (UMTS) is envisioned as the successor to Global System for Mobile Communications (GSM). UMTS signals the move into the third generation (3G) of mobile networks. UMTS also addresses the growing demand of mo-bile and Internet applications for new capacity in the overcrowded mobile communica-tions sky. The new network increases transmission speed to 2 Mbps per mobile user and establishes a global roaming standard.

6.2 Overview

UMTS, also referred as wideband code division multiple access (W-CDMA), is one of the most significant advances in the evolution of telecommunications into 3G networks. UMTS allows many more applications to be introduced to a worldwide and provides a vital link between today's multiple GSM systems and the ultimate single worldwide stan-dard for all mobile telecommunications, International Mobile Telecommunications-2000 (IMT-2000).

In the next pages it is explained the GSM evolution from 2G to 3G, then, the architecture of UMTS and the protocols, interfaces, and technologies that go along with it.


60

6.3 2G to 3G: GSM Evolution

Phase 1 of the standardization of GSM900 was completed by the European Telecom-munications Standards Institute (ETSI) in 1990 and included all necessary definitions for the GSM network operations. Several tele-services and bearer services have been de-fined (including data transmission up to 9.6 kbps), but only some very basic supplemen-tary services were offered. As a result, GSM standards were enhanced in Phase 2 (1995) to incorporate a large variety of supplementary services that were comparable to digital fixed network integrated services digital network (ISDN) standards. In 1996, ETSI decided to further enhance GSM in annual Phase 2+ releases that incorporate 3G capa-bilities.

GSM Phase 2+ releases have introduced important 3G features such as intelligent net-work (IN) services with customized application for mobile enhanced logic (CAMEL), en-hanced speech compression/decompression (CODEC), enhanced full rate (EFR), and adaptive multirate (AMR), high-data rate services and new transmission principles with high-speed circuit-switched data (HSCSD), general packet radio service (GPRS), and enhanced data rates for GSM evolution (EDGE). UMTS is a 3G GSM successor stan-dard that is downward-compatible with GSM, using the GSM Phase 2+ enhanced core network.


61

6.4 UMTS Network architecture

UMTS (Rel. '99) incorporates enhanced GSM Phase 2+ Core Networks with GPRS and CAMEL. This enables network operators to enjoy the improved cost-efficiency of UMTS while protecting their 2G investments and reducing the risks of implementation.

In UMTS release 1 (Rel. '99), a new radio access network UMTS terrestrial radio access network (UTRAN) is introduced. UTRAN, the UMTS radio access network (RAN), is connected via the Iu to the GSM Phase 2+ core network (CN). The Iu is the UTRAN in-terface between the radio network controller (RNC) and CN; the UTRAN interface be-tween RNC and the packet-switched domain of the CN (Iu-PS) is used for PS data and the UTRAN interface between RNC and the circuit-switched domain of the CN (Iu-CS) is used for CS data. "GSM-only" mobile stations (MSs) will be connected to the network via the GSM air (radio) interface (Um). UMTS/GSM dual-mode user equipment (UE) will be connected to the network via UMTS air (radio) interface (Uu) at very high data rates (up to almost 2 Mbps). Outside the UMTS service area, UMTS/GSM UE will be connected to the network at reduced data rates via the Um.

Maximum data rates are 115 kbps for CS data by HSCSD, 171 kbps for PS data by GPRS, and 553 kbps by EDGE. Handover between UMTS and GSM is supported, and handover between UMTS and other 3G systems (e.g., multicarrier CDMA [MC-CDMA]) will be supported to achieve true worldwide access. The public land mobile network (PLMN) described in UMTS Rel. '99 incorporates three major categories of network ele-ments:

GSM Phase 1/2 core network elements: mobile services switching center (MSC), visitor location register (VLR), home location register (HLR), authentication center (AC), and equipment identity register (EIR);

GSM Phase 2+ enhancements: GPRS (serving GPRS support node [SGSN] and gateway GPRS support node [GGSN]) and CAMEL (CAMEL service environ-ment [CSE]);

UMTS specific modifications and enhancements, particularly UTRAN.


62

6.4.1 Network elements from GSM Phase 1/2

The GSM Phase 1/2 PLMN consists of three subsystems: the base station subsystem (BSS), the network and switching subsystem (NSS), and the operations support system (OSS). The BSS consists of the functional units: base station controller (BSC), base transceiver station (BTS) and transcoder and rate adapter unit (TRAU). The NSS con-sists of the functional units: MSC, VLR, HLR, EIR, and the AC. The MSC provides func-tions such as switching, signaling, paging, and inter-MSC handover. The OSS consists of operation and maintenance centers (OMCs), which are used for remote and central-ized operation, administration, and maintenance (OAM) tasks.

The following picture shows the UMTS Phase 1 Network.


63

6.4.2 Network elements from GSM Phase 2 +

GPRS

The most important evolutionary step of GSM toward UMTS is GPRS. GPRS introduces PS into the GSM CN and allows direct access to packet data networks (PDNs). This en-ables high-data rate PS transmission well beyond the 64 kbps limit of ISDN through the GSM CN, a necessity for UMTS data transmission rates of up to 2 Mbps. GPRS pre-pares and optimizes the CN for high-data rate PS transmission, as does UMTS with UT-RAN over the RAN. Thus, GPRS is a prerequisite for the UMTS introduction.

Two functional units extend the GSM NSS architecture for GPRS PS services: the GGSN and the SGSN. The GGSN has functions comparable to a gateway MSC (GMSC). The SGSN resides at the same hierarchical level as a visited MSC (VMSC)/VLR and therefore performs comparable functions such as routing and mobility man-agement.

CAMEL

CAMEL enables worldwide access to operator-specific IN applications such as prepaid, call screening, and supervision. CAMEL is the primary GSM Phase 2+ enhancement for the introduction of the UMTS virtual home environment (VHE) concept. VHE is a plat-form for flexible service definition (collection of service creation tools) that enables the operator to modify or enhance existing services and/or define new services. Further-more, VHE enables worldwide access to these operator-specific services in every GSM and UMTS PLMN and introduces location-based services (by interaction with GSM/UMTS mobility management). A CSE and a new common control signaling system 7 (SS7) (CCS7) protocol, the CAMEL application part (CAP), are required on the CN to introduce CAMEL.


64

6.4.3 Network elements from UMTS Phase 1

As mentioned above, UMTS differs from GSM Phase 2+ mostly in the new principles for air interface transmission (W-CDMA instead of time division multiple access [TDMA]/frequency division multiple access [FDMA]). Therefore, a new RAN called UTRAN must be introduced with UMTS. Only minor modifications, such as allocation of the transcoder (TC) function for speech compression to the CN, are needed in the CN to accommodate the change. The TC function is used together with an interworking function (IWF) for pro-tocol conversion between the A and the Iu-CS interfaces.

UTRAN

The UMTS standard can be seen as an extension of existing networks. Two new net-work elements are introduced in UTRAN, RNC, and Node B. UTRAN is subdivided into individual radio network systems (RNSs), where each RNS is controlled by an RNC. The RNC is connected to a set of Node B elements, each of which can serve one or several cells.

Existing network elements, such as MSC, SGSN, and HLR, can be extended to adopt the UMTS requirements, but RNC, Node B, and the handsets must be completely new designs. RNC will become the replacement for BSC, and Node B fulfills nearly the same functionality as BTS. GSM and GPRS networks will be extended, and new services will be integrated into an overall network that contains both existing interfaces such as A, Gb, and Abis, and new interfaces that include Iu, UTRAN interface between Node B and RNC (Iub), and UTRAN interface between two RNCs (Iur).

UMTS defines four new open interfaces:

Uu: UE to Node B (UTRA, the UMTS W-CDMA air interface;

Iu: RNC to GSM Phase 2+ CN interface (MSC/VLR or SGSN);

Iu-CS for circuit-switched data;

Iu-PS for packet-switched data.


65

Iub: RNC to Node B interface;

Iur: RNC to RNC interface, not comparable to any interface in GSM.

The Iu, Iub, and Iur interfaces are based on ATM transmission principles.

The following picture shows the UTRAN architecture.

The RNC enables autonomous radio resource management (RRM) by UTRAN. It per-forms the same functions as the GSM BSC, providing central control for the RNS ele-ments (RNC and Node Bs).


66

The RNC handles protocol exchanges between Iu, Iur, and Iub interfaces and is respon-sible for centralized operation and maintenance (O&M) of the entire RNS with access to the OSS. Because the interfaces are ATM-based, the RNC switches ATM cells between them. The user's circuit-switched and packet-switched data coming from Iu-CS and Iu-PS interfaces are multiplexed together for multimedia transmission via Iur, Iub, and Uu interfaces to and from the UE.

The RNC uses the Iur interface, which has no equivalent in GSM BSS, to autonomously handle 100 percent of the RRM, eliminating that burden from the CN. Serving control functions such as admission, RRC connection to the UE, congestion and handover/macro diversity are managed entirely by a single serving RNC (SRNC).

If another RNC is involved in the active connection through an inter-RNC soft handover, it is declared a drift RNC (DRNC). The DRNC is only responsible for the allocation of code resources. A reallocation of the SRNC functionality to the former DRNC is possible (serving radio network subsystem [SRNS] relocation). The term controlling RNC (CRNC) is used to define the RNC that controls the logical resources of its UTRAN access points.


67

Node B

Node B is the physical unit for radio transmission/reception with cells. Depending on sectoring (omni/sector cells), one or more cells may be served by a Node B. A single Node B can support both FDD and TDD modes, and it can be co-located with a GSM BTS to reduce implementation costs. Node B connects with the UE via the W-CDMA Uu radio interface and with the RNC via the Iub asynchronous transfer mode (ATM)-based interface. Node B is the ATM termination point.

The main task of Node B is the conversion of data to and from the Uu radio interface, including forward error correction (FEC), rate adaptation, W-CDMA spreading/despreading, and quadrature phase shift keying (QPSK) modulation on the air interface. It measures quality and strength of the connection and determines the frame error rate (FER), transmitting these data to the RNC as a measurement report for handover and macro diversity combining. The Node B is also responsible for the FDD softer handover. This micro diversity combining is carried out independently, eliminating the need for ad-ditional transmission capacity in the Iub.


68

The Node B also participates in power control, as it enables the UE to adjust its power using downlink (DL) transmission power control (TPC) commands via the inner-loop power control on the basis of uplink (UL) TPC information. The predefined values for inner-loop power control are derived from the RNC via outer-loop power control.

UMTS UE

The UMTS UE is based on the same principles as the GSM MS - the separation be-tween mobile equipment (ME) and the UMTS subscriber identity module (SIM) card (USIM). The following picture shows the user equipment functions. The UE is the coun-terpart to the various network elements in many functions and procedures.


69

6.5 UMTS Interfaces

Many new protocols have been developed for the four new interfaces specified in UMTS: Uu, Iub, Iur, and Iu. Before we review the individual interface protocols, we introduce the UMTS general protocol model.

General Protocol Model [3G TS 25.401]

UTRAN interface consists of a set of horizontal and vertical layers (see next picture). The UTRAN requirements are addressed in the horizontal radio network layer across dif-ferent types of control and user planes. Control planes are used to control a link or a connection; user planes are used to transparently transmit user data from the higher layers. Standard transmission issues, which are independent of UTRAN requirements, are applied in the horizontal transport network layer.


70

Five major protocol blocks are shown in the previous picture:

Signaling bearers are used to transmit higher layers' signaling and control in-formation. They are set up by O&M activities.

Data bearers are the frame protocols used to transport user data (data streams). The transport network-control plane (TN-CP) sets them up.

Application protocols are used to provide UMTS-specific signaling and control within UTRAN, such as to set up bearers in the radio network layer.

Data streams contain the user data that is transparently transmitted between the network elements. User data is comprised of the subscriber's personal data and mobility management information that are exchanged between the peer entities MSC and UE.

Access link control application part (ALCAP) protocol layers are provided in the TN-CP. They react to the radio network layer's demands to set up, maintain, and release data bearers. The primary objective of introducing the TN-CP was to totally separate the selection of the data bearer technology from the control plane (where the UTRAN-specific application protocols are located). The TN-CP is pre-sent in the Iu-CS, Iur, and Iub interfaces. In the remaining interfaces where there is no ALCAP signaling, preconfigured data bearers are activated.

Application Protocols

Application protocols are Layer-3 protocols that are defined to perform UTRAN-specific signaling and control. A complete UTRAN and UE control plane protocol architecture is illustrated in the next picture. UTRAN-specific control protocols exist in each of the four interfaces.


71

Iu: Radio Access Network Application Part (RANAP) [3G TS 25.413]

This protocol layer provides UTRAN-specific signaling and control over the Iu. The fol-lowing is a subset of the RANAP functions:

Overall radio access bearer (RAB) management, which includes the RABís setup, maintenance, and release;

Management of Iu connections;

Transport of nonaccess stratum (NAS) information between the UE and the CN; for example, NAS contains the mobility management signaling and broadcast information;

Exchanging UE location information between the RNC and CN;

Paging requests from the CN to the UE;

Overload and general error situation handling.


72

Iur: Radio Network Sublayer Application Part (RNSAP) [3G TS 25.423]

UTRAN-specific signaling and control over this interface contains the following:

Management of radio links, physical links, and common transport channel re-sources;

Paging;

SRNC relocation;

Measurements of dedicated resources.

Iub: Node B Application Part (NBAP) [3G TS 25.433]

UTRAN specific signaling and control in the Iub includes the following:

Management of common channels, common resources, and radio links;

Configuration management, such as cell configuration management;

Measurement handling and control;

Synchronization (TDD);

Reporting of error situations.

Uu: Radio Resource Control (RRC) [3G TS 25.331]

This layer handles the control plane signaling over the Uu between the UE and the UT-RAN. Some of the functions offered by the RRC include the following:

Broadcasting information;

Management of connections between the UE and the UTRAN, which include their establishment, maintenance, and release;


73

Management of the radio bearers, which include their establishment, mainte-nance, release, and the corresponding connection mobility;

Ciphering control;

Outer loop power control;

Message integrity protection;

Timing advance in the TDD mode;

UE measurement report evaluation;

Paging and notifying.

Two modes of operation are defined for the UE, the idle mode and the dedicated mode. In the idle mode the peer entity of the UE's RRC is at the Node B, while in the dedicated mode it is at the SRNC. The dedicated mode is shown in Figure 10.

Higher-layer protocols to perform signaling and control tasks are found on top of the RRC. The mobility management (MM) and call control (CC) are defined in the existing GSM specifications. Even though MM and CC occur between the UE and the CN and are therefore not part of UTRAN specific signaling, they demand basic support from the transfer service, which is offered by duplication avoidance (see 3G TS 23.110). This layer is responsible for in-sequence transfer and priority handling of messages. It be-longs to UTRAN, even though its peer entities are located in the UE and CN.

Transport Network Layer: Specific Layer-3 Signaling and Control Protocols

Two types of layer-3 signaling protocols are found in the transport network layer:

Iu, Iur: Signaling Connection Control Part (SCCP) [ITU-T Q.711-Q. 716] This provides connectionless and connection-oriented services. On a connection-oriented link, it separates each mobile unit and is responsible for the establishment of a connection-oriented link for each and every one of them;


74

lu-CS, Iur, Iub: ALCAP [ITU-T Q.2630.1, Q.2150.1, and Q.2150.2]. Layer-3 signaling is needed to set up the bearers to transmit data via the user plane. This function is the responsibility of the ALCAP, which is applied to dynamically estab-lish, maintain, release, and control ATM adaptation layer (AAL)-2 connections. AL-CAP also has the ability to link the connection control to another higher layer con-trol protocol. This and additional capabilities were specified in ITU-T Q.2630.1. Be-cause of the protocol layer specified in Q.2630.1, a converter is needed to corre-spond with underlying sublayers of the protocol stack. These converters are called (generically) signaling transport converter (STC). Two converters are defined and applied in UTRAN:

Iu-CS, Iur: AAL-2 STC on message transfer part (MTP) level 3 (broad-band) for Q.2140 (MTP3b) [Q.2150.1];

Iub: AAL-2 STC on service-specific connection-oriented protocol (SSCOP) [Q.2150.2].

Transport Network Layer Specific Transmission Technologies

Now that we have a circuit-switched and packet-switched domain in the CN and a grow-ing market for packet-switched network solutions, a new RAN must be open to both types of traffic in the long run. That network must also transmit the Layer-3 signaling and control information. ATM was selected as the Layer-2 technology, but higher-layer proto-cols used in the transport network layer demonstrate the UMTS openness to a pure IP solution.

Iu, Iur, Iub: ATM [ITU-T I.361]

Broadband communication will play an important role with UMTS. Not only voice but also multimedia applications such as videoconferencing, exploring the Internet, and docu-ment sharing are anticipated. We need a data link technology that can handle both circuit-switched and packet-switched traffic as well as isochronous and asynchronous traffic. In UMTS (Release í99), ATM was selected to perform this task.


75

An ATM network is composed of ATM nodes and links. The user data is organized and transmitted in each link with a stream of ATM cells. AALs are defined to enable different types of services with corresponding traffic behavior. Two of these are applied in UT-RAN:

Iu-CS, Iur, Iub: AAL-2 [ITU-T I.363.2]-With AAL-2, isochronous connections with variable bit rate and minimal delay in a connection-oriented mode are sup-ported. This layer was designed to provide real-time service with variable data rates, such as video. Except for the Iu-PS interface, AAL-2 is always used to carry the user data streams;

Iu-PS, Iur, Iub: AAL-5 [ITU-T I.363.5]-With AAL-5, isochronous connections with variable bit rate in a connection-oriented mode are supported. This layer is used for Internet protocol (IP) local-area network (LAN) emulation, and signaling. In UTRAN, AAL-5 is used to carry the packet-switched user traffic in the Iu-PS-interface and the signaling and control data throughout.

In order to carry signaling and control data, the AAL-5 has to be enhanced. Here, UT-RAN offers both a classical ATM solution and an IP-based approach:

Signaling AAL and MTP3b - To make signaling AAL (SAAL) available in place of the AAL-5 service-specific convergence sublayer (SSCS), the SSCOP, which provides a reliable data transfer service, and the service-specific coordination func-tion (SSCF), which acts as coordination unit, are defined;

Iu, Iur, Iub: SSCOP [ITU-T Q.2110] - The SSCOP is located on top of the AAL. It is a common connection-oriented protocol that provides a reliable data transfer between peer entities. Its capabilities include the transfer of higher-layer data with sequence integrity, flow control, connection maintenance in case of a longer data transfer break, error correction by protocol control information, error correction by retransmission, error reporting to layer management, status report, and more.


76

Two versions of the SSCF are defined: one for signaling at the user-to-network interface (UNI), and one for signaling at the network to node interface (NNI):

Iub: SSCF for at the UNI (SSCF) [ITU-T Q.2130] - The SSCF-UNI receives Layer-3 signaling and maps it to the SSCOP and visa versa. The SSCF-UNI per-forms coordination between the higher and lower layers. Within UTRAN, it is ap-plied in Iub with the NBAP and ALCAP on top of the SSCF-UNI.

Iu, Iur: SSCF at the NNI (SSCF-NNI) [ITU-T Q.2140] - The SSCF-NNI re-ceives the SS7 signaling of a Layer 3 and maps it to the SSCOP, and visa versa. The SSCF-NNI performs coordination between the higher and the lower layers. Within UTRAN, MTP3b has the higher Layer 3, which requires service from the SSCOP-NNI.

Originally the SS7 protocol layer, SCCP relies on the services offered by MTP, so the Layer-3 part of the MTP must face the SCCP layer:

Iu, Iur: MTP3b [ITU-T Q.2210] - Signaling links must be controlled in level 3 for: message routing, discrimination and distribution (for point-to-point link only), signaling link management, load sharing, etc. The specific functions and messages for these are defined by the MTP3b, which requires the SSCF-NNI to provide its service.

The Layer-3 signaling and control data can also be handled by an enhanced IP stack us-ing a tunneling function (see Figure 12). Tunneling is also applied for packet-switched user data over the Iu-PS interface (see Figure 14).

IP over ATM

lu-PS, Iur: IP [IETF RFC 791, 2460, 1483, 2225], user datagram protocol (UDP) [IETF RFC 768] The IP can be encapsulated and then transmitted via an ATM connection, a process which is described in the RFC 1483 and RFC 2225. Both IP version 4 (IPv4) and IP version 6 (IPv6) are supported. IP is ac-tually a Layer-3 protocol. UDP is applied on top of the unreliable Layer-4 pro-


77

tocol. The objective is to open this signaling link to future pure IP network so-lutions.

In order to tunnel SCCP or ALCAP signaling information, two protocols are applied:

Iu-PS and Iur: Simple Control Transmission Protocol (SCTP) [IETF SCTP] - This protocol layer allows the transmission of signaling protocols over IP networks. Its tasks are comparable with MTP3b. On Iu-CS, SS7 must be tunneled between the CN and the RNC. The plan is that this is to be done with the Iu-PS and Iur [IETF M3UA].

The following does the tunneling of packet-switched user data:

Iu-PS: GPRS tunneling protocol (GTP) [3G TS 29.060] - The GTP provides signaling through GTP-control (GTP-C) and data transfer through GTP-user (GTP-U) procedures. Only the latter is applied in the Iu-PS interface because the control function is handled by the RANAP protocol. The GTP-U is used to tunnel user data between the SGSN and the RNC.

Iu, Iur, Iub: The Physical Layers [3G TS 25.411]

The physical layer defines the access to the transmission media, the physical and elec-trical properties, and how to activate and deactivate a connection. It offers to the higher-layer physical service access points to support the transmission of a uniform bit stream. A huge set of physical-layer solutions is allowed in UTRAN, including ETSI synchronous transport module (STM)-1 (155 Mbps) and STM-4 (622 Mbps); synchronous optical net-work (SONET) synchronous transport signal (STS)-3c (155 Mbps) and STS-12c (622 Mbps); ITU STS-1 (51 Mbps) and STM-0 (51 Mbps); E-1 (2 Mbps), E-2 (8 Mbps), and E-3 (34 Mbps); T-1 (1.5 Mbps) and T-3 (45 Mbps); and J-1 (1.5 Mbps) and J-2 (6.3 Mbps).


78

With the previous protocol layers, the interfaces Iu, Iur, and Iur are fully described. There is only the air interface left for a more detailed analysis:

The Air Interface Uu [3G TS 25.301]

The air interface solution is usually a major cause for dispute when specifying a new RAN. Figure 15 shows the realization of the lower parts of the protocol stack in the UE. As can be seen, a physical layer, data link layer, and network layer (the part for the RRC) have been specified.


79

The physical layer is responsible for the transmission of data over the air interface. The FDD and TDD W-CDMA solutions have been specified in UMTS Rel. '99. The data link layer contains four sublayers:

Medium Access Control (MAC) [3G TS 25.321] - The MAC layer is located on top of the physical layer. Logical channels are used for communication with the higher layers. A set of logical channels is defined to transmit each specific type of information. Therefore, a logical channel determines the kind of information it uses. The exchange of information with the physical layer is realized with transport chan-nels. They describe how data is to be transmitted over the air interface and with what characteristics. The MAC layer is responsible for more than mapping the logi-cal channels into the physical ones. It is also used for priority handling of UEs and the data flows of a UE, traffic monitoring, ciphering, multiplexing, and more.

Radio Link Control (RLC) [3G TS 25.322] - This is responsible for acknowl-edged or unacknowledged data transfer, establishment of RLC connections, trans-parent data transfer, quality of service (QoS) settings, unrecoverable error notifica-tion, ciphering, etc. There is one RLC connection per radio bearer.

The two remaining Layer-2 protocols are used only in the user plane:

Packet Data Convergence Protocol (PDCP) [3G TS 25.323] - This is respon-sible for the transmission and reception of radio network layer protocol data units (PDUs). Within UMTS, several different network layer protocols are supported to transparently transmit protocols. At the moment, IPv4 and IPv6 are supported, but UMTS must be open to other protocols without forcing the modification of UTRAN protocols. This transparent transmission is one task of PDCP; another is to in-crease channel efficiency (by protocol header compression, for example).

Broadcast/Multicast Control (BMC) [3G TS 25.324] - This offers broadcast/multicast services in the user plane. For instance, it stores SMS CB messages and transmits them to the UE.


80

7. TRENDY Suite7.1 Overview

The purpose of the Trendy Suite, as mentioned before, is to recovery and catalogue the reports of the HTSs and DNCPs devices (the DNCP name is used to indicate the whole nodes of the intelligent network, e.g. SRN - MNP Signaling Relay Node used for Mobile Number Portability). Rather than the DNCP reports, that are sent directly from the de-vices to the server, the HTS reports are received by the NFM server and then they are sent to the server which runs the Trendy Batch Service.

All these reports are stored into a Microsoft Access database; such a database resides in the same server that hosts the Trendy Batch Service and the Trendy server.

The suite is composed of three applications:

Trendy Batch Service;

Trendy Client;

Trendy Server;

and allows two types of users:

Administrator;

Guest.

All the three applications are built with Microsoft Visual Basic 6, that is an event driven programming language (a computer programming paradigm in which the flow of the pro-gram is determined by user actions or messages from others programs) and associated development environment from Microsoft.


81

Visual Basic was designed to be easy to learn and use. The language not only allows pro-grammers to easily create simple GUI applications, but also has the flexibility to develop fairly complex applications as well. Programming in VB is a combination of visually arrang-ing components or controls on a form, specifying attributes and actions of those compo-nents, and writing additional lines of code for more functionality. Since default attributes and actions are defined for the components, a simple program can be created without the programmer having to write many lines of code. Performance problems were experienced by earlier versions, but with faster computers and native code compilation this has become less of an issue.

Because of the above mentioned reason and to allow easy updates, such a language has been chosen to be used for the development of the suite's applications.

In the following pages I will provide a brief overview on how the Trendy Batch Service and the Trendy Client works, then I will point out what I have done to build in my own part of code.

7.1.1 Trendy Batch Service

The Trendy Batch Service is a daemon (a daemon is a computer program that runs in the background, rather than under the direct control of a user, it is usually initiated as process), such a daemon runs on the server located in our office. Its main task is to re-covery, on a daily basis, all the devices' logs. To do that, every day at 9:00 am, it con-nects automatically to the NFM server and runs a script that resides on the NFM, such a script starts to recovery the logs sent by the HTSs, once all logs are recovered it filters those logs depending on certain parameters and sends the lowered bunch of logs to the Trendy Batch Service.

As said in the overview, the process to recovery DNCPs' logs is simpler than the previ-ous mentioned, that is because each DNCP device sends its own logs to the Trendy Batch Service every day, that is possible cause each DNCP runs a Crontab process (Crontab is a Unix process that let you schedule some operation in a definite time).

After these two process, the Trendy Batch Service filters the logs again, in a way to avoid to overcharge the database with logs useless for the technicians.


82

The following are three examples of logs, the first belongs to an HTS, the second and the third belongs to a DNCP, note that the third one is a System Alarm:

HTS

-------->> Pattern di ricerca: arb "BKUP ODD"

070323010054A0020ä +++ MIHTS01 07-03-23 01:00:53 MTCE 4113 #009411 >

BKUP ODD STARTED

END OF REPORT #009411 ++-

070323010118A0020ä +++ MIHTS01 07-03-23 01:01:17 MTCE 4113 #009412 >

BKUP ODD NRODD= 1 IN PROGRESS

END OF REPORT #009412 ++-

DNCP

## CONTROLLO HW ##

CLAIM - - Online - 0

0 GBUS Nexus CLAIM - - Online - 0

g27210 0/0 PMERC Nexus CLAIM 50116 8.0 Online - 0

- 0/0/0 CPU Adapter CLAIM - - Online - 0

m71700 0/0/1 MEM Adapter CLAIM - - Online - 0

g27210 0/1 PMERC Nexus CLAIM 500899 8.0 Online - 0

DNCP System Alarm

## SYSLOG ##

May 16 2007 23:59:00METDST: syslog.log trimmed by bkup_syslog.sh

T h u M a y 1 7 0 0 : 0 1 : 0 0 2 0 0 7 0 . 0 6 4 8 3 5 1 0 . 1 9 2 . 2 . 5 2 4 1 5 7 5 /home/sdp/stat/quarter_hour/sdp_stats.20070517.0000 a _ o r misure ftp 0 * 1179352860 0.000000

Thu May 17 00:01:00 2007 -1 X -1 X X X X X X ftp -1 X 1179352860 0.000000

May 16 23:54:52 NASRF04 : su : + tty?? root-sdp

May 17 00:03:00 NASRF04 SINAP 0 [3599]: SINAP ALARM


83

7.1.2 Trendy Client

The Trendy Client application has the task to show the reports stored in the database. It is used by the technicians to monitor the network activity.

File menu - Allows the user to close the application, such an operation could be even done by clicking on the exit button located in the left side of the window;

Visualizza menu - It allows the user to access the main function of the appli-cation (Diario di centrale), that is to access the reports database;

Utility menu - Impostazione parametri - It allows the user to configure the ap-plication's parameters;

? menu - Shows the application's name and its version.


84

The following is a thorough overview of the Client's functions.

Application configuration

The "Utility -> Configurazione" menu let you access the configuration window, it contains the database path that is essential for the data recovery.

The database resides in the server, it is possible to manually insert the path or to chose it by clicking on the button in the left side of the path text-box.


85

Data visualization

The "Visualizza -> Diario di centrale" menu let you access the data visualization window.

The first window shown let you select the search keys. By default neither HTS nor SM nor Key are selected, thus the visualization includes all HTSs, all SMs and all Keys, the selected date is the last loaded in the database. Notice that each user is able to edit only his own HTSs.

By clicking on the "Conferma" button the requested data are shown. See next picture. The search keys are shown in the upper side of the window, while in the body it is shown the HTS table.


86

Double clicking on a row let you see a window with the HTS reports list.

To see a report details just double click on the report row.


87

These are the details of the selected report:


88

Data visualization criterion

The data capture is done in relation to the following search keys (example of HTSs' keys):

7.2 Trendy Server

7.2.1 Overview

The Trendy Server application runs on the main server and it has to be used only by administrators users.

Its main purpose is to allow users to manage the whole Trendy Suite, thus an adminis-trator could add, delete, or edit a client account, a device, a key and so on.

The main window has three menus, the first is the file menu, it has the only purpose to let you close the application, right as the Client's file menu does. Anyway it can be even closed by clicking on the exit button in the left side of the window.

The third menu shows general information about the application.


89

The core functions of the application can be found in the second menu: Utility.

I developed the following forms (a part of the code is shown in the final part of the book):

Gestione Elenco Client - Manages the users that can access the Trendy ap-plications;

Gestione Apparati - Manages the devices that can be controlled;

Gestione Elenco KEY DNCP - Manages the keys used to filter DNCPs re-ports;

Gestione Elenco KEY - Manages the keys used to filter HTSs reports;

Gestione Elenco SM - Manages the associations between HTS and SM;

Impostazione Parametri - Manages the application's parameters.

The following forms has been developed by my colleague:

Gestione Utenti e Psw - Manages users' passwords;

Importa descrizioni Point Code - Imports Point Codes' descriptions from an Oracle database.


90

7.2.2 Gestione Elenco Client

The window shows all the users that can access Trendy applications, and even if they are administrators or simple users.

I open the database by putting in the form_load a function written by my colleague, this function, along with other functions, is defined in a module called "Funzioni".

If Not dbGiaAperto(dbTrendy) Then

If Not ApriDatabase(dbTrendy, DBPath & "\" & DBName, False, False, wsTrendy) Then

MsgBox "Impossibile aprire il database " & DBPath & "\" & DBName, vbExclamation, glTitolo

Exit Sub

End If

End If

If the boolean function "dbGiaAperto" returns a negative value (that means the database is still closed), the "ApriDatabase" function opens the database. If something goes wrong, an error alert is shown and the subroutine quits immediately.


91

To select elements from tables I set a string variable in which store the SQL query, then I call a function to open the database (that function has been written by my colleague), the following is an example:

Dim strSQL As String

strSQL = "Select * from ElencoClient" 'select each elements from the client table

If Not ApriRecordSet(strSQL, RS, dbTrendy, dbOpenDynaset, 0, 0, False) Then

MsgBox "Impossibile aprire il recordset: " & strSQL & " - " & Errore, vbExclamation, glTitolo

Errore = ""

Exit Sub

End If

The "ApriRecordSet" function tries to create a recordset (that is nothing more than a vir-tual table) containing the query results. Even here, if something goes wrong, an error alert is shown and the subroutine quits immediately.

To show the user list I used the MSFlexGrig control, that is a powerful control to manage data from database tables.

From this window an administrator can insert, delete or edit a user account, moreover, he can manage the devices associated to a particular user:

Add Accounts

By clicking on the "Inserisci" button, on the top right part, the "Inserisci Client" window it is shown, it allows you to type in the name of the new user account and to select if the new user is a simple user or an administra-tor;


92

The "Pulisci" button clears all the fields, the "Chiudi" button close the window while the "Inserisci" button saves the introduced data. Of course, if the typed name already exists, the application warns the administrator and doesn't save the record.

The process of adding a new record in a table is very simple, first it is necessary to check if the record already exist (RS is the recordset):

If RS.RecordCount > 0 Then 'if the recordset is not empty

Do While Not RS.EOF 'until the end of the recordset

If DeCrypt(RS.Fields("UtentePC").Value) = utente Then 'if the user already exist

controlloUtente = False 'the function returns false

Exit Function

Else

controlloUtente = True 'else it returns true

End If

RS.MoveNext 'it moves to the next record

Loop

End If

then it is just enough to add the following instructions:

RS.AddNew 'starts the add procedure

RS.Fields("UtentePC").Value = Crypt(Me.textUtente.text) 'inserts the name in the name field

If Me.optionNo Then 'if administrator is not checked

RS.Fields("TipoL").Value = Crypt("NO") 'inserts "NO" in the type field

else

RS.Fields("TipoL").Value = Crypt("NO") 'else it inserts "SI" in the type field

end if

RS.Update 'updates the recordset

The "Crypt" and "DeCrypt" functions are used either to cipher and decipher text.


93

Delete Accounts

To delete an user account, the only thing to do is to select an user and then click on the "Elimina" button, the account is deleted instantly.

The only instruction necessary to delete a record is:

RS.Delete

clearly it is necessary to seek the record before to delete it.

Edit Accounts

By clicking on the "Modifica" button, the "Modifica Client" window it is shown, it shows the name of the selected user and if he is an administratorThe "Pulisci" and the "Chiudi" buttons have the same functions of those in the "Inserisci Client" window, while the "Modifica" button saves the changes.

To edit a record it is just enough to seek that record and then to replace its field's values by using the following code:

RS.Edit 'starts the edit procedure

RS.Fields("UtentePC").Value = Crypt(Me.textUtente.text) 'replace the user name

RS.Fields("TipoL").Value = Crypt("NO") 'replace the user type

RS.Update 'updates the recordset


94

Manage associated devices

Double clicking on a user name shows the "5ESS - DNCP Associati" winodw, such a window shows the devices associated to the selected user:

The "Associa apparato al Client" button adds the se-lected device to the se-lected user, while the "Rimuovi apparato dal Cliet" removes the selected de-vices from the selected user.


95

7.2.3 Gestione Apparati

The "Gestione Apparati" window let you add, delete or edit devices, moreover it let you see the SMs devices associated to the HTSs:

Add Devices

By clicking on the "Inserisci" button the "Inserici apparato" window is shown:


96

From here an administrator can chose to add a "5ESS" device, that is a HTS, or a DNCP device, the only thing to do is to select the radio button and to type the name. It is also possible to associ-ate a SM device to a HTS, by the way, you have to select at least one SM for each HTS, otherwise the application doesn't save the new device. If the SM you want is not in the list, you can even add a new SM by clicking on the "Aggiungi SM" button. When you check the DNCP radio button the SM chose list disappears, that is because DNCPs haven't SM associated.

This picture shows the "Inserisci apparato" window when the DNCP radio button is checked.


97

Delete Devices

To delete a device it is just necessary to select the device you want delete, then to click on the "Elimina" button.

Edit Devices

First of all it is necessary to select the device you want to edit, then to click on the "Modifica" button; the "Modifica Apparato" window is now shown, it shows the device's attributes, such attributes in-clude the device name, its type, and, if it is a HTS device, the window shows the SMs associated to that HTS.

Obviously from here it is possible to change all the attributes, even the device type.


98

Associated SMs

The "Gestione Apparati" window gives also the chance to see which SMs are associated to a certain HTS, it is needed to double click on the name of one of the HTSs, then the following window is shown:


99

7.2.4 Gestione Elenco KEY DNCP

The "Gestione Elenco KEY DNCP" window let you add, edit or delete the keywords used to filter the DNCPs reports:

Add Key

By clicking on the "Inserici" button the "In-serisci KEY DNCP" window is shown, from here it is possible to add a new key for the DNCP reports, as with the others input win-dow, the application checks first if the key already exists, then it saves the record.

Delete Key

To delete a key it is just enough to select a key and then to click on the "Elimina" but-ton.


100

Edit Key

The "Modifica" button allows you to edit a previous selected key, the only thing to do now is to replace the shown name.

7.2.5 Gestione Elenco KEY

The "Gestione Elenco Key" window allows you to add, edit or delete the keywords for the HTSs reports, it works as well as the "Gestione Elenco KEY DNCP" does.


101

7.2.6 Elenco SM

The "Elenco SM" window shows all the SMs and the HTSs devices, it allows the administrator to associate SMs to HTSs, to remove SMs from HTSs and also to add a new SM on the list of the available SMs.

The "Seleziona tutti i 5ESS" button se-lects all the SMs in the list, while the "Deseleziona tutti i 5ESS" deselects all of them.

The "Associa SM su 5ESS" button adds the selected SMs on the chosen HTS, while the "Rimuovi SM da 5ESS" has the reverse function.

One of the most important functions that can be accomplished from here is the inclusion of a new SM, such a task can be done by clicking on the "Aggi-ungi SM alla lista". On the other hand, to remove a SM from the list, it is needed to select the SM and click on the "Elimina SM dalla lista" button.

In the "Aggiungi SM" window an user can type the name of the new SM and can chose the HTS to associate with the SM; at least one HTS has to be chosen.


102

7.2.7 Impostazione Parametri

From the "Impostazione Parametri" window an administrator can set the parameters necessary to let the "Trendy Batch Service" work.

The window is divided in five tabs, each tab contains dif-ferent types of parameters, such parameters are stored into an ini file called TrendySetup.ini. Ini files are very simple to understand, they have a format like the following:

[SESSION 1]

;comment.

parameter = example

parameter 2 = example

......

[SESSION 2]

;comment

parameter = example

parameter 2 = example

......

To add, delete and read a string from the ini file I used two functions already written

by my colleague, the one that read a string is the following:

LeggiStrIni session, parameter, file-path


103

it requires only three parameters: the file ini path, the session name and the parameter name.

To add and delete a string I used the same function but with different parameters, for ex-ample to add a string I used:

ScriviStrIni session, parameter, value, file-path

where parameter and value are the new values to insert in the session field. On the other hand, to delete a string, i used:

ScriviStrIni session, parameter, vbNullString, file-path

vbNullString in the value field does means that the string with that parameter and in that session has to be deleted.

In the first tab of the window (the "Generale" tab shown in the previous picture), there are general parameters:

"Percorso database" - Database path;

"Nome database" - Database name (e.g. Trendy.mdb);

"Percorso DNCP" - Path of the DNCP logs;

"SMTP Server" - Name of the SMTP server, for the outgoing email;

"SMTP Porta" - SMTP server port;

"Da" - Email address of the sender;

"Indirizzo IP NFM primario" - IP address of the primary NFM server;

"Indirizzo IP NFM secondario" - IP address of the secondary NFM server;

"Tempo attesa prima di chiudere la connessione" - NFM connection timeout.


104

The second tab, "Acquisizione", let you set the parameter for the HTS reports recovery:

"Recupera giorni non caricati" - Recovery of the previous days (Yes or No);

"Attesa" - Delay for the recovery;

"Giorni da recuperare" - Number of days to retrieve;

"Cancella log HTS" - Delete log files (Yes or No).

The following picture shows the "Acquisizione" tab:


105

The "Filtri DNCP" tab let you chose which items can be shown and the minimum values for each filter, the following picture shows the "Filtri DNCP" tab:

From here it is also possible to add or remove filters; to delete a filter just select a filter then click on the "Elimina filtro selezionato" button. To add a filter click on the "Aggiungi nuovo filtro" button, a text-box and two buttons now appears:

In the "Filtro" text-box you can type the name of the new filter, then you can click on the "Conferma" button, if the filter doesn't already ex-ist, it is added in the data-base, else the application alerts you that the filter al-ready exist.

By clicking on the "Annulla" button the text-box and the two button disappear.


106

The "Alllarmi" tab let you add or remove filters for different system alarms, it allows you to manage alarm logs for CS, MNP and TWIN devices.

On the right side of the win-dow you can chose the type of alarm you want to add, then you can write the name of the alarm and add it by clicking on the "Aggiungi al-larme" button.

As in the "Filtri DNCP" but-ton, from here you can re-move a filter just selecting it and clicking on the "Rimuovi allarme" button.

The last tab is the "Indirizzi e-mail" tab, it let you chose which users can receive emails from the server when a particular event happens. Furthermore it allows you to add and remove an email. The tab is composed of two lists, the first one lists the email addresses of the users that can receive emails when the recovery of the reports is done; the sec-ond one lists the email addresses of the users that can receive emails when an error log or an alert log is received. The following picture shows the "Indirizzi e-mail" tab:


107

The user can select the email addresses that can receive emails from the server.

To add a email address click on the "Aggiungi" button, in the shown window you can select if the address can be able to receive emails when the recovery is done or when there is an error or alarm log, then a click on the "Inserisci" button let you save the ad-dress.

To remove an email it is necessary to click on the "Rimuovi" button, the shown window let you select which addresses to remove; also here it is necessary to spec-ify the type of email you want to remove; a click on the "Elimina" button com-pletes the operation.


108

8. SIGTRAN & EAGLE 58.1 SIGTRAN

8.1.1 SIGTRAN Definition and overview

Definition

Signaling Transport (SIGTRAN) is a new set of standards defined by the International Engineering Task Force (IETF). This set of protocols has been defined in order to pro-vide the architectural model of signaling transport over IP networks.

Overview

The communication industry is going through a period of explosive change that is both enabling and driving the convergence of services. Data is becoming more significant as a proportion of traffic compared to voice. Operators are seeking ways to consolidate voice and data traffic, platforms, and services in order to reduce the operational, mainte-nance, and initial cost of the network. With a number of technological solutions to choose from, Internet protocol (IP) is now considered the most promising media on which to build the new integrated services. There is an on-going integration of circuit networks and IP networks. Fixed and mobile telephone network operators are designing all-IP architecture, which includes support for signaling system 7 (SS7) signaling proto-cols. IP provides an effective way to transport user data and for operators to expand their networks and build new services. Mass popularization of communication services, including short message services (SMS), contribute to the rapid growth of signaling net-works. As such, more scalable and flexible networks, such as the Internet and its tech-nologies, are needed.

The benefits of using an IP network in comparison to a legacy time division multiplex (TDM)-based network include:


109

Ease of deployment - When using signaling gateways (such as access service group [ASG]), there is no need to disrupt the existing SS7 network, and future en-hancements are transparent;

Less costly equipment - There is no need for further expensive investments in the legacy signaling elements;

Better efficiency - SIGTRAN over an IP network doesn't require the physical E1/T1 over synchronous digital hierarchy (SDH) rings. Using new technologies like IP over SDH and IP over fiber, for instance, can achieve much higher throughput;

Higher bandwidth - SIGTRAN information over IP does not constrain to link capacity as it does in the SS7 network. The IP network is much more flexible than the TDM-based legacy network;

Enhanced services - Implementing a core IP network facilitates a variety of new solutions and value-added services (VAS).

Using SIGTRAN protocols such as an MTP3 user application (M3UA) and a signaling connection control part user application (SUA), the application vendor (i.e Short Mes-sage service center [SMSC], IP-home location register [IP-HLR], and so on) only has to develop the application layer and does not have to deal with the complex SS7 interfaces. By making the network introduction complexity and integration problem much shorter, the time for marketing these new applications will be much faster. SS7 over IP also solves the throughput limitation that was inherited from the SS7 standards, thus allowing high-end machines like SMSC, HLR, and so on to be able to support heavy SS7 traffic needs.

By using signaling gateways, both legacy and new equipment can seamlessly continue to operate over high bandwidth, scalable and available IP-based core network, instead of burdening the TDM-based legacy SS7 network.


110

The following picture depicts the diversity of solutions achieved by using signaling trans-port protocols:

8.1.2 Why develop a new transport protocol?

Transmission Control Protocol (TCP) (RFC793) performs an enormous service as the primary transport protocol in the means of reliable data transfer in IP networks. However, because it was defined a long time ago and was designed as a packet-oriented protocol, TCP imposes several limitations for new emerging applications. An increasing number of recent applications have found TCP too limiting.


111

Some of the limitations include the following:

Reliability mechanisms - TCP provides both reliable data transfer, through ac-knowledgments mechanism, and strict order of transmission delivery of data, through sequencing mechanism. Some applications need reliable transfer without sequence maintenance, while others would be satisfied with partial ordering of the data. In both of these cases the head-of-line blocking caused by TCP adds unnec-essary delay;

Real-time issues - The abovementioned acknowledgment mechanism (which added the unnecessary delay) makes the TCP inappropriate for real-time applica-tions;

TCP sockets - The limited scope of TCP sockets complicates the task of pro-viding highly available data transfer capability using multi-homed hosts;

Security issues - TCP is relatively vulnerable to denial-of-service attacks.

All the abovementioned limitations of TCP are relevant while trying to transport SS7 signaling over IP networks, and this is the direct motivation for the development of SCTP as a new transport protocol for SIGTRAN. SCTP has not been developed solely for SIG-TRAN; thus SCTP may be a good solution for the requirements of other applications.

8.1.3 SIGTRAN Protocol architecture

The architecture that has been defined by SIGTRAN work group consist 3 components:

A standard IP.

A common signaling transport protocol - A protocol that supports a common set of reliable transport functions for signaling transport. In particular, SCTP is a new transport protocol that has been defined by the IETF.


112

An adaptation sub-layer that supports specific primitives, such as manage-ment indications, required by a particular signaling application protocol. Several new adaptation sub-layer protocols have been defined by the IETF: M2PA, M2UA, M3UA, SUA, and IUA. Only one protocol has to be implemented at a given time.

8.1.4 SCTP - Stream Control Transport Protocol

Overview

SCTP is a new IP transport protocol, which exists at an equivalent level with TCP and user datagram protocol (UDP) and which currently provides transport layer functions to many Internet-based applications. SCTP has been approved by the IETF as a proposed standard, and is specified in RFC 2960.


113

Architectural View of SCTP

SCTP is architecturally viewed as a layer between the SCTP user adaptation layer and a connectionless packet network service such as IP . The basic service offered by SCTP is a reliable transfer of user messages between peer SCTP users. SCTP is connection ori-ented; thus it establishes a connection between two endpoints (called association in SCTP context) before transmitting the user data itself.

Functional View of SCTP

The SCTP transport service can be fragmented into several functionalities. These func-tions are depicted in the following picture.


114

Note: "SCTP user" refers to adaptation protocol in this context.

Association Startup and Teardown - An association is initiated by a request from the SCTP user. A cookie mechanism is employed during the initialization to provide protection against security attacks;

Sequenced Delivery within Streams - The SCTP user can specify at associa-tion startup time the number of streams to be supported by the association;

User Data Fragmentation - SCTP supports fragmentation and reassembly of user messages to ensure that the SCTP packet passed to the lower layer conforms to the path multiple-tenant unit (MTU);

Acknowledgment and Congestion Avoidance - SCTP assigns a transmission sequence number (TSN) to each user data message (fragment or unfragmented). The receiving end acknowledges all TSNs received, even if there are gaps in the sequence;

Chunk Bundling - The SCTP packet delivered to the lower layer consists of a common header followed by one or more chunks;

Packet Validation - A mandatory verification tag field and a 32-bit checksum field are included in the SCTP common header;

Path Management - The SCTP path-management function chooses the desti-nation transport address for each outgoing SCTP packet based on the SCTP user's instructions and the currently perceived reach-ability status of the eligible destina-tion set;

SCTP Common Header Format

The following table depicts the common header format of SCTP:


115

Source/Destination Port Number Field: 16 Bits - Indicates the SCTP sender's/destination's port number;

Verification Tag Field: 32 Bits - The receiver of this packet uses the verification tag to validate the sender of this SCTP packet;

Checksum Field: 32 Bits - This field contains the checksum of this SCTP packet. SCTP uses the Adler-32 algorithm for calculating the checksum.

8.1.5 M2PA - Message Transfer Part 2 Peer-to-Peer Adaptation

M2PA defines a protocol supporting the transport of SS7 MTP3 signaling messages over IP, using the services of the SCTP. M2PA allows for full MTP3 message-handling and network-management capabilities between any two SS7 nodes communicating over an IP network. M2PA supports:

Seamless operation of MTP3 protocol peers over an IP network connection;

The MTP2/MTP3 interface boundary, management of SCTP transport asso-ciations, and traffic instead of MTP2 links;

Asynchronous reporting of status changes to management.

The MTP specification requires that each node with an MTP3 layer will be represented by an SS7 point code. Thus, each IP signaling point must have its own SS7 point code.


116

8.1.6 M2UA

M2UA defines a protocol for transport of SS7 MTP2 user (e.g. MTP3) signaling mes-sages over IP using SCTP. The only SS7 MTP2 user is MTP3. M2UA provides support for:

MTP2/MTP3 interface boundary;

Communication between layer-management modules;

Support for management of active associations.

8.1.7 M3UA Message Transfer Part 3 User Adaptation

M3UA defines a protocol for supporting the transport of any SS7 MTP3 user signaling (e.g., ISUP/SCCP messages) over IP using the services of the SCTP. This protocol would be used between an SG and a media gateway controller (MGC) or IP-resident da-tabase. M3UA is suitable for transfer messages of any MTP3 user part. The list of these protocol layers includes, but is not limited to, ISUP, SCCP, and telephone user part (TUP). Note: Transaction capabilities application protocol (TCAP) or radio access net-work application protocol (RANAP) messages are transferred transparently by the M3UA as SCCP payload because they are SCCP user protocols.

The M3UA layer provides the equivalent set of primitives at its upper layer to the MTP3 users as provided by the MTP3 to its local MTP3 users at an SS7 signaling endpoint. In this way, the ISUP and/or SCCP layer aren't aware that the expected MTP3 services are offered remotely from an MTP3 layer at an SG, and not by a local MTP3 layer. The MTP3 layer at an SG may also be unaware that its local users are actually remote user parts over M3UA. In practice, the M3UA extends access to the MTP3 layer services to a remote IP-based application.


117

8.1.8 SUA

SUA defines a protocol for the transport of any SS7 SCCP user signaling (e.g., TCAP, RANAP, etc.) over IP using SCTP services. The protocol is designed to be modular and symmetric so as to allow it to work in diverse architectures such as an SG-to-IP signaling-endpoint architecture as well as a peer-to-peer IP Signaling Endpoint architec-ture. SUA supports the following:

Transfer of SCCP user part messages (TCAP, RANAP, etc.);

SCCP connectionless service;

SCCP connection oriented service;

Management of SCTP transports associations between a SG and one or more IP-based signaling nodes;

Distributed IP-based signaling nodes;

Asynchronous reporting of status changes to management.


118

8.2 Lucent - Tekelec EAGLE 5

The whole signaling traffic of VODAFONE Italia network, related to Voice, Mobility, SMS, MMS and Value Added Services, currently transported on TDM backbone based on Lu-cent HTS, will be gradually moved to a new SIGTRAN backbone based on Tekelec Ea-gle 5 platforms.

The new Backbone infrastructure will be based on IP/MPLS transport; SIGTRAN proto-col will be used both in backbone and peripheral connections: in particular:

SIGTRAN connection between SEP and Eagle 5 will be based on M3UA pro-tocol;

SIGTRAN connection between Eagle 5 and Eagle 5 will be based on M2PA protocol.

The picture below shows the protocol stacks that will be used in the new SIGTRAN net-work; in addition, TDM low speed links may be used to connect Eagle 5 to “legacy” SEPs that will not be enabled to SIGTRAN or for SCCP interconnection towards other Net-works.


119

8.2.1 Eagle 5 Network Architecture

As the current TDM backbone, the new SIGTRAN backbone will be split in two layers:

“Voice” layer: mobility and voice services related SCCP signaling traffic;

SMS layer: SMS related SCCP signaling traffic.

As far as the number of Zones is concerned, they will be reduced as the new SIGTRAN network will be logically divided in two Regions, each one will include two Zones:

Region A: includes Zone 1 and Zone 2;

Region B: includes Zone 3 and Zone 4.

The number of Eagle 5 nodes that will be deployed in VF-IT network is 8, split in 4 on “Voice” layer and 4 on SMS layer.

8.2.2 Logical connections

The connection between two Eagle platforms is realized by means of a M2PA/SCTP/IP based link set. In particular at least two M2PA/SCTP links, which appear to the MTP3 level as normal MTP2 links belonging to normal link sets, will be configured for each link set.

The connection between Eagle and SIGTRAN enabled SEPs is realized by means of a M3UA/SCTP/IP based link set. The number of SCTP associations that will be configured for each IP Linkset, may vary depending on the HW and SW capabilities of the SEP. Currently the maximum number of SCTP associations (i.e. IP links) that can be defined on Eagle 5 in an IP Linkset for M3UA is 8.

In addition, TDM Low Speed Linksets may be necessary to connect Eagle to “legacy” SEPs that will not be enabled to SIGTRAN or for interconnection to other Networks.


120

The following picture summarizes the logical connections of the Eagle 5 platforms; the figure applies both for “Voice” layer and SMS layer:

Furthermore, TDM High Speed Link connections will be built between Eagle 5 and leg-acy STPs (i.e. HTS) belonging to the same Region. These connections are required, during migration of SEPs to SIGTRAN network, to convey signaling traffic between SIG-TRAN enabled SEPs – connected to Eagle 5 SGWs – and “legacy” SEPs – connected to TDM based STPs.

The following picture shows an example of logical TDM connection between Eagle 5 and HTS based on High Speed Links.


121

8.2.3 Physical connections

Tekelec Eagle 5 platform is a carrier grade, reliable and scalable Signaling Gateway/STP. Database and interface functions are performed on various card types:

DSM cards for Global Title Translation and other Database features;

IPGW cards for M3UA interface protocol;

IPLIM cards for M2PA interface protocol;

HC-MIM cards for Low Speed Link and High Speed Link TDM interfaces.

SIGTRAN connections – both in case of M3UA and M2PA connections – will be realized by means of groups of SCTP associations, called IP linksets.

The following picture shows an example of IP linkset for M3UA connection between Ea-gle 5 and Nokia MSC Server; in order to spread the signaling traffic on the cards and to protect the linkset against card failures, each SCTP association composing the IP linkset is defined on a different IPGW card.


122

SCTP associations are multi-homed, that is multiple IP addresses are assigned to each SCTP peer of the association; multi-homing gives reliability to SCTP associations in many cases of IP network failure. For this purpose two FastEthernet interfaces of one SIGTRAN board will home each SCTP association, as shown in the following picture:

The relevant parameters of SCTP associations for M3UA protocol are the following:

Path Max Retransmit: 2 - which sets the maximum number of packet and keep-alive retries before the corresponding IP destination address is marked inac-tive;

Association Max Retransmit: 4 - which sets the maximum number of packet and keep-alive retries before the peer end point is marked as unreachable and the association is closed reporting the failure to the upper layer;

Min and Max Retransmit Timeout: 300, 600 - which mean the min and max retransmission timer values are 300 ms and 600 ms, respectively. The summation


123

of the first Path Max Retransmit retransmission timer values (starting for its min value and doubling the previous value with max value as upper limit) gives the time before a new remote IP peer is tried by the local peer;

Keepalive: 1000 - which means that keepalive messages (exchanged be-tween SCTP peers to monitor the availability of SCTP association remote IP ad-dresses, even if no traffic is sent towards that IP address) is sent every 1 sec;

Bundling: Yes - which means that the user application allows more than one chunk within a SCTP packet.

The relevant parameters of SCTP associations for M2PA protocol are the following:

Path Max Retransmit: 4 - which sets the maximum number of packet and keep-alive retries before the corresponding IP destination address is marked inac-tive;

Association Max Retransmit: 8 - which sets the maximum number of packet and keep-alive retries before the peer end point is marked as unreachable and the association is closed reporting the failure to the upper layer;

Min and Max Retransmit Timeout: 225, 600 - which mean the min and max retransmission timer values are 225 ms and 600 ms, respectively.

Keepalive: not set - as keepalive messages (exchanged between SCTP peers to monitor the availability of SCTP association remote IP addresses, even if no traf-fic is sent towards that IP address) are sent every Min Retransmit Timeout + 500 ms;

Bundling: Yes - which means that the user application allows more than one chunk within a SCTP packet.


124

Conclusions

This thesis has presented the work I have done in these five months of stage in Voda-fone: I started to talk about the company and the major technologies used, and then I pointed out my role in the team I joined in.

In the next pages I would want to briefly describe the hugest problems I encountered during the development of my part of code and the solutions I took on to solve those problems; eventually I would like to express my opinions about the stage.

The biggest problems I encountered mainly concern the dialog between VB 6 and the access database, the files ini management, the MSFlexGrid items management and the horizontal scroll in the ListBox items. As I previous mentioned, my work has been made easier by the use of functions already written by my colleague. Those that I mainly used are:

ApriDatabase - It opens the chosen database. I use it every time I need to open a database;

ApriRecordSet - It opens a table from an already open database, it needs a SQL query to work, the query results is stored in a "recordset" variable set by the user;

dbGiaAperto - It checks if the chosen database is already open;

Crypt & DeCrypt - They use a specific algorithm to crypt and decrypt text; they are very useful cause all database contents have to be encrypted;

LeggiStrIni - It reads the file ini contents. It needs the file path, the session and the name of the field to read;

ScriviStrIni - It writes in a ini file, it needs the file path, the session, the field name and the text to write in.


125

By using the first three functions I listed before, i solved many of the issues concerning the database management: in fact they allowed me to open and close the database connection with few code rows, for instance, to open a database and at the same time to check if it is already open, it is enough to write the following rows:

If Not dbGiaAperto(dbTrendy) Then If Not ApriDatabase(dbTrendy, DBPath & "\" & DBName, False, False, wsTrendy) Then MsgBox "Impossibile aprire il database " & DBPath & "\" & DBName, vbExclamation, glTitolo Exit Sub End If End If

The parenthetical "dbTrendy" indicates the database name, "dbGiàAperto" checks if the database is already open, if it isn't open the database is opened by the "ApriDatabase" function. To open a table it is enough to write the following code:

Dim strSQL As String strSQL = "Select * from ElencoClient" 'select each elements from the client table If Not ApriRecordSet(strSQL, RS, dbTrendy, dbOpenDynaset, 0, 0, False) Then MsgBox "Impossibile aprire il recordset: " & strSQL & " - " & Errore, vbExclamation, glTitolo Errore = "" Exit Sub End If

After the query variable has been made, it is enough to call the "ApriRecordSet" function with the appropriate parameters. The result is stored in the RS "recordset", such a "re-cordset" can now be easily edit with its own functions: .Add, .Delete, .MoveNext, .Move-Last, .MoveFirst, .Update.

Pertain to the files ini management, my main issue has been to delete a string in an ini file; as a matter of fact, with the "ScriviStrIni" and "LeggiStrIni" functions, it is very simple to write and read from an ini file, but at a first glance, it is not so simple to delete a string. After a brief internet search, I figured out that to delete a string it is just enough to re-place a parameter in the "ScriviStrIni" function, to be more precise, by putting the "vbNullString" string instead of the text to write, the parameter is totally deleted.


126

During the use of the MSFlexGrid item I coped with many problems, the main ones con-cerned the up and down scrolling and the rows highlighting.

For the first one I found the solution on the internet. It consists of two functions that have to be written in the code: they allow to scroll the text up and down. The functions need a file called "MSSCCPRJ.SCC" to work, such a file must be placed in the same folder of the project files. The functions are called respectively "ScrollUp" and "ScrollDown". In order to make them work it is necessary to specify which MSFlexGrid they are going to work for.

To highlight the MSFlexGrid rows I used a part of code previously written by my col-league; the code works in the following way: once a row is clicked, the row's color is stored into a variable, then the row is colored of yellow. If the user click on another row, the old one retrieves its old color and the previous procedure is performed again with the new row. I included all this code in a function called "evidenziaFlex".

I had to face another problem about the scrolling when I managed ListBox items and es-pecially the one that lists the email addresses: in fact I often had to list email addresses larger than the ListBox width, then it has been necessary to use the horizontal scroll, which for default is not included with the ListBox. I found the solution in an internet fo-rum: it consists of few code rows that use some system functions to determine the di-mension of the largest string in the list, then the horizontal scroll bar is opportunely di-mensioned.

Finally I believe that I have been very lucky to join in Vodafone. These five months here gave me the chance to understand how a big company operates and its internal dynam-ics; furthermore I learned how to write good code in Visual Basic 6, I learned how the Vodafone core network is composed, how it works and which types of technologies and protocols it uses.

I think that all the experience and knowledge I gained during the biennial course at Elis, plus the amazing experience in Vodafone, give me a solid background on which I can build my own career.


127

Acknowledgments

I here would like to thank the people who made this thesis possible. I have the pleasure to thank Stefano Gollinucci, my thesis advisor, and Marie Christine Giuliano: she taught me the basic of Visual Basic 6 and helped me getting started in the developing of the Trendy Server application.

I am honored for being given the chance of working with Stefano Gollinucci and his staff. I would like to address my special thanks to all of them. This thesis would not have been possible without their remarkable patience and prompt guidance in my way. I am particu-larly grateful to Luciano Contaldi for the huge amount of time he spent to give me no-tions about the Vodafone network.

I would like to thank the staff of the "Centro Elis" college: they gave me the opportunity to live almost two years of my life in a homely place, surrounded by friendly and valorous people; furthermore they gave me the opportunity to work in a big company like Voda-fone and the big honor to join in a very qualified team. Many thanks to Domenico Pontari and Michele Gavasci: they always encouraged me and provided me support. Special thanks to Emilio Tonelli and Cristian D'Aloisi, for their big support along the course.

I could not end this remark without addressing a warm thank you to my parents and my sister for inspiring me to aspire and for give me their moral support and belief in every-thing I do.


128

Attachment - Trendy Server Demo Code

Listed here is some code of the Trendy Server (only little bunches of code that I made on my own). This code is presented here only to give a brief demonstration of the Visual Basic programming style.

This first part shows the code of the "Gestione Client" form:

Option Explicit

Dim topRow As IntegerDim RS As RecordsetDim RSquery As RecordsetDim oldCol As Integer, oldRow As Integer, nowCol As Integer, nowRow As IntegerDim oldColor As VariantDim cliccato As Boolean

Private Sub cmdElimina_Click()On Error GoTo Errore_cmdElimina_Click If RS.RecordCount > 0 Then 'If flex.Rows > 0 Then If Me.flex.Col > 0 Then flex.Row = Me.flex.Row 'mi posiziono sul testo da eliminare flex.Col = Me.flex.Col - 1 ' \\ elimina (flex.Text) Me.flex.Col = 0 End If End If oldCol = 0 oldRow = 0Exit SubErrore_cmdElimina_Click: MsgBox "Si è verificato un errore all'interno della Sub 'cmdElimina_Click' nel form 'frmClient'."End Sub


129

Public Sub cmdInserisci_Click() frmInserisciClient.Show vbModalEnd Sub

Private Sub cmdModifica_Click() If RS.RecordCount > 0 Then If cliccato = True Then frmModificaClient.Show vbModal End If End IfEnd Sub

Private Sub cmdChiudi_Click() Unload MeEnd Sub

Private Sub flex_Click()On Error GoTo Errore_flex_ClickDim i As Integer cliccato = True 'indico che ho cliccato si flex e quindi ho selezionato un campo With flex 'salvo le coordinate della cella selezionata nowCol = .Col nowRow = .Row 'se esistono le coordinate di una selezione precedente rimetto sfondo bianco If oldRow > 0 Then For i = 0 To .Cols - 1 .Col = i 'oldCol .Row = oldRow .CellBackColor = oldColor '&H80000005 'bianco Next i End If 'imposto le coordinate correnti ed imposto sfondo giallo For i = 0 To .Cols - 1 '.Col = nowCol .Col = i .Row = nowRow 'salvo il colore come old oldColor = .CellBackColor .CellBackColor = &H80FFFF 'giallino Next i 'salvo le coordinate correnti come old oldCol = nowCol oldRow = nowRow End WithExit Sub

Errore_flex_Click: MsgBox "Si è verificato un errore all'interno della Sub 'flex_Click' nel form 'frmClient'."End Sub

Private Sub flex_DblClick()On Error GoTo Errore_flexD Screen.MousePointer = vbHourglass frmClientHTS.Show vbModalExit Sub

Errore_flexD: MsgBox "Si è verificato un errore all'interno della Sub 'flex_DblClick' nel form 'frmClient'."End Sub


130

Private Sub Form_Load() 'public *in caso di erroreOn Error GoTo Errore_Form_LoadDim X As Integer, ctl As Control, lngResult As Long, i As Integer cliccato = False 'dico che non e' ancora stato selezionato un campo (lo uso per la modifica) Left = (Screen.Width - Width) / 2 ' Centra il form orizzontalmente. Top = (Screen.Height - Height) / 2 ' Centra il form verticalmente. If Not dbGiaAperto(dbTrendy) Then If Not ApriDatabase(dbTrendy, DBPath & "\" & DBName, False, False, wsTrendy) Then MsgBox "Impossibile aprire il database " & DBPath & "\" & DBName, vbExclamation, glTitolo Exit Sub End If End If ' caricaRS ' set the module level callback pointer lpFormObj = ObjPtr(Me) SetProp frmClient.hwnd, "PrevWndProc", SetWindowLong(frmClient.hwnd, GWL_WNDPROC, AddressOf WndProc) topRow = 1 visualizza With flex .TextMatrix(0, 0) = "Utente" .TextMatrix(0, 1) = "Amministratore"' .ColWidth(0) = 1860' .ColWidth(1) = 1860 For i = 0 To .Cols - 1 .Row = 0 .Col = i .FillStyle = flexFillRepeat .CellFontBold = True .CellAlignment = flexAlignCenterCenter .AllowUserResizing = flexResizeBoth .BackColorBkg = vbWhite 'Background of cellwhen it is selected .BackColorSel = vbYellow 'Forecolor of cell when it is selected .ForeColorSel = vbBlack 'Backcolor of cell when it is unselected 'Forecolor of cell when it is unselected .ForeColor = vbBlack .GridColor = vbBlack Next End With Exit SubErrore_Form_Load: MsgBox "Si è verificato un errore all'interno della Sub 'form_load' nel form 'frmClient'."End Sub

Public Sub visualizza()On Error GoTo Errore_visualizzaDim vett() As StructARUtentiPC, temp As StructARUtentiPC, i As Integer, j As Integer, color As Boolean, test As Boolean, X As Integer caricaRS If RS.RecordCount > 0 Then RS.MoveLast RS.MoveFirst X = RS.RecordCount If X < 30 Then flex.ColWidth(0) = 2000 flex.ColWidth(1) = 2000 Else flex.ColWidth(0) = 1860 flex.ColWidth(1) = 1860 End If ''''''''''''riempio i vettori


131

ReDim vett(X) For j = 0 To RS.RecordCount - 1 vett(j).Nome = DeCrypt(RS.Fields("UtentePC").Value) vett(j).Tipo = DeCrypt(RS.Fields("TipoL").Value) RS.MoveNext Next '''''''''''''ordino il vettore For i = 0 To X - 1 For j = i + 1 To X If StrComp(UCase(vett(i).Nome), UCase(vett(j).Nome), 1) = 1 Then temp = vett(i) vett(i) = vett(j) vett(j) = temp End If Next Next '''''''''''riempio la colonna degli utenti RS.MoveFirst flex.Rows = RS.RecordCount + 1 j = 1 i = 1 color = True Do While Not RS.EOF flex.TextMatrix(i, 0) = vett(j).Nome flex.Row = i flex.Col = 0 If color = True Then flex.CellBackColor = &H80000009 Else flex.CellBackColor = &H8000000F End If flex.CellAlignment = flexAlignCenterCenter '''''''''riempio la colonna del tipo flex.TextMatrix(i, 1) = vett(j).Tipo flex.Row = i flex.Col = 1 If color = True Then flex.CellBackColor = &H80000009 Else flex.CellBackColor = &H8000000F End If flex.CellAlignment = flexAlignCenterCenter color = Not color RS.MoveNext i = i + 1 j = j + 1 Loop Else flex.Rows = 2 flex.ColWidth(0) = 2000 flex.ColWidth(1) = 2000 flex.TextMatrix(1, 0) = "" flex.TextMatrix(1, 1) = "" End If 'RS.recordcount > 0Exit SubErrore_visualizza: MsgBox "Si è verificato un errore all'interno della Sub 'visualizza' nel form 'frmClient'."End Sub

Public Sub ScrollUp()On Error GoTo Errore_ScrollUp ' scroll up..


132

If RS.RecordCount > 29 Then If topRow > 1 Then topRow = topRow - 1 flex.topRow = topRow End If End IfExit SubErrore_ScrollUp: MsgBox "Si è verificato un errore all'interno della Sub 'ScrollUp' nel form 'frmClient'."End Sub

Public Sub ScrollDown()On Error GoTo Errore_ScrollDown ' scroll down.. If RS.RecordCount > 29 Then If topRow < flex.Rows - 1 Then topRow = topRow + 1 flex.topRow = topRow End If End IfExit SubErrore_ScrollDown: MsgBox "Si è verificato un errore all'interno della Sub 'ScrollDown' nel form 'frmClient'."End Sub

Public Function returnNomeModifica() As String 'restituisce il nome selezionato sulla flexgrid da utilizzare per la modificaOn Error GoTo Errore_return If Me.flex.Col > 0 Then flex.Row = Me.flex.Row flex.Col = Me.flex.Col - 1 returnNomeModifica = flex.Text End If 'Me.flex.Col = 0Exit FunctionErrore_return: MsgBox "Si è verificato un errore all'interno della Function 'returnNomeModifica' nel form 'frmClient'."End Function

Private Function elimina(utente As String) As Boolean 'controlla se esiste un nome utente selezionato e lo eliminaOn Error GoTo Errore_eliminaDim idClient As Integer, queryC_H As String, RSc_h As Recordset If RS.RecordCount > 0 Then RS.MoveLast RS.MoveFirst Do While Not RS.EOF If DeCrypt(RS.Fields("UtentePC").Value) = utente Then idClient = RS.Fields("ID").Value RS.Delete visualizza Exit Do End If RS.MoveNext Loop End If 'RS.recordcount > 0 'ora elimino il client e gli apparati associati dalla tabella ElencoC_H 'creo un recordset con l'elenco degli hts associati ai client queryC_H = "Select * from ElencoC_H order by C" If Not ApriRecordSet(queryC_H, RSc_h, dbTrendy, dbOpenDynaset, 0, 0, False) Then MsgBox "Impossibile aprire il recordset: " & queryC_H & " - " & Errore, vbExclamation, glTitolo Errore = "" Exit Function End If


133

'cerco ed elimino i record If RSc_h.RecordCount > 0 Then RSc_h.MoveLast RSc_h.MoveFirst Do While Not RSc_h.EOF If RSc_h.Fields("C").Value = idClient Then RSc_h.Delete End If RSc_h.MoveNext Loop End IfExit FunctionErrore_elimina: MsgBox "Si è verificato un errore all'interno della Function 'elimina' nel form 'frmClient'."End Function

Private Sub caricaRS()On Error GoTo Errore_caricaDim tsql As String tsql = "Select * from ElencoClient" ' order by UtentePC" If Not ApriRecordSet(tsql, RS, dbTrendy, dbOpenDynaset, 0, 0, False) Then MsgBox "Impossibile aprire il recordset: " & tsql & " - " & Errore, vbExclamation, glTitolo Errore = "" Exit Sub End IfExit SubErrore_carica: MsgBox "Si è verificato un errore all'interno della Sub 'caricaRS' nel form 'frmClient'."End Sub

Public Function ottieniID() As Long 'restituisco l'ID del Client selezionatoOn Error GoTo Errore_ottDim tsql As String, client As String If RS.RecordCount > 0 Then RS.MoveLast RS.MoveFirst flex.Row = Me.flex.Row flex.Col = Me.flex.Col '- 1 client = Crypt(flex.Text) tsql = "Select ID from ElencoClient where UtentePC= " & Chr(34) & client & Chr(34) ' order by UtentePC" If Not ApriRecordSet(tsql, RSquery, dbTrendy, dbOpenDynaset, 0, 0, False) Then MsgBox "Impossibile aprire il recordset: " & tsql & " - " & Errore, vbExclamation, glTitolo Errore = "" Exit Function End If ottieniID = RSquery.Fields("ID").Value End If Exit FunctionErrore_ott: MsgBox "Si è verificato un errore all'interno della Sub 'ottieniID' nel form 'frmClient'."End Function


134

This second part shows the code of the "Elenco SM" form:

Option Explicit

Dim topRow As IntegerDim RShts As RecordsetDim RSsm As RecordsetDim RSsmEDIT As RecordsetDim oldCol As Integer, oldRow As Integer, nowCol As Integer, nowRow As IntegerDim oldColor As VariantDim cliccato As Boolean, test As Boolean

Private Sub cdmDisa_Click() 'rimuove l'sm selezionato dagli hts selezionatiOn Error GoTo Errore_disaDim i As Integer, HTSselezionato As Boolean, idhts As Integer, RStemp As RecordsetDim sqlQuery As String, val As Integer HTSselezionato = False If Me.flex.Row > 0 And Me.flex <> "" Then 'se ho selezionato un SM val = Me.flex RShts.MoveFirst If list.ListCount > 0 Then ' se ci sono HTS in lista For i = 0 To list.ListCount - 1 If list.Selected(i) = True Then 'se l'hts e' selezionato HTSselezionato = True 'almeno un HTS e' selezionato 'controllo se l'hts selezionato ha sm associati idhts = RShts.Fields("ID").Value 'prendo l'id dell'hts selezionato 'carico un recordset con tutti gli sm associati all'hts selezionato sqlQuery = "Select * from ElencoSM where IDHTS =" & idhts If Not ApriRecordSet(sqlQuery, RStemp, dbTrendy, dbOpenDynaset, 0, 0, False) Then MsgBox "Impossibile aprire il recordset: " & sqlQuery & " - " & Errore, vbExclamation, glTitolo Errore = "" Exit Sub End If 'ApriRecordSet If RStemp.RecordCount > 0 Then 'se ci sono sm associati faccio il controllo RStemp.MoveLast RStemp.MoveFirst Do While Not RStemp.EOF If RStemp.Fields("SM").Value = val Then 'se l'sm e' uguale RStemp.Delete ' lo elimino Exit Do


135

End If 'altrimenti non faccio niente RStemp.MoveNext Loop End If 'RStemp.RecordCount > 0 End If 'list.Selected(i) = Tru RShts.MoveNext Next i If HTSselezionato = False Then ' se non ci sono hts selezionati MsgBox "Devi selezionare almeno un 5ESS!" Exit Sub End If 'HTSselezionato = False End If 'list.ListCount > 0 Else ' se non ho selezionato SM MsgBox "Devi selezionare almeno un SM!" Exit Sub End If 'Me.flex.Row > 0 MsgBox "SM rimossi con successo!"Exit SubErrore_disa: MsgBox "Si è verificato un errore all'interno della Sub 'cdmDisa_Click' nel form 'frmElencoSM'."End Sub

Private Sub cmdAddSM_Click() frmAddNewSM.Show vbModalEnd Sub

Private Sub cmdAnnulla_Click() Unload Me End Sub

Private Sub caricaRSsmEDIT() 'carica il recordset utilizzato per la modifica della lista degli smOn Error GoTo Errore_csmeDim sqlSM As String sqlSM = "Select * from ElencoSM order by SM" If Not ApriRecordSet(sqlSM, RSsmEDIT, dbTrendy, dbOpenDynaset, 0, 0, False) Then MsgBox "Impossibile aprire il recordset: " & sqlSM & " - " & Errore, vbExclamation, glTitolo Errore = "" Exit Sub End IfExit SubErrore_csme: MsgBox "Si è verificato un errore all'interno della Sub 'caricaRSsmEDIT' nel form 'frmElencoSM'."End Sub

Private Sub cmdAssocia_Click() 'associa l'sm alla agli hts selezionatiOn Error GoTo Errore_assDim i As Integer, idhts As Integer, RStemp As Recordset, sqlQuery As String, SMesistente As BooleanDim val As Integer, HTSselezionato As Boolean caricaRSsmEDIT 'carico un recordset con sm e hts per la modifica SMesistente = True HTSselezionato = False If Me.flex.Row > 0 And Me.flex <> "" Then ' se l'sm e' selezionato val = Me.flex If list.ListCount > 0 Then 'se ci sono hts RShts.MoveFirst 'parto dal primo hts For i = 0 To list.ListCount - 1 'controllo tutti gli hts in lista If list.Selected(i) = True Then 'se l'hts e' selezionato HTSselezionato = True 'almeno un HTS e' selezionato 'controllo se l'hts selezionato ha sm associati idhts = RShts.Fields("ID").Value 'prendo l'id dell'hts selezionato 'carico un recordset con tutti gli sm associati all'hts selezionato sqlQuery = "Select * from ElencoSM where IDHTS =" & idhts


136

If Not ApriRecordSet(sqlQuery, RStemp, dbTrendy, dbOpenDynaset, 0, 0, False) Then MsgBox "Impossibile aprire il recordset: " & sqlQuery & " - " & Errore, vbExclamation, glTitolo Errore = "" Exit Sub End If If RStemp.RecordCount = 0 Then 'se non ci sono sm associati ' aggiungo quello selezionato senza fare controlli RSsmEDIT.AddNew RSsmEDIT.Fields("IDHTS").Value = idhts RSsmEDIT.Fields("SM").Value = val RSsmEDIT.Update Else ' se ci sono sm associati 'faccio il controllo se esiste gia lo stesso sm RStemp.MoveLast RStemp.MoveFirst Do While Not RStemp.EOF If RStemp.Fields("SM").Value = val Then 'se l'sm e' uguale SMesistente = True Exit Do Else SMesistente = False RStemp.MoveNext End If 'RStemp.Fields("SM").Value = Me.flex Loop If SMesistente = False Then 'se non ci sono sm uguali 'lo aggiungo RSsmEDIT.AddNew RSsmEDIT.Fields("IDHTS").Value = idhts RSsmEDIT.Fields("SM").Value = val RSsmEDIT.Update End If 'SMesistente = False End If 'RStemp.RecordCount = 0 End If 'If list.Selected(i) = True RShts.MoveNext ' passo all'altro HTS Next i If HTSselezionato = False Then ' se non ci sono hts selezionati MsgBox "Devi selezionare almeno un 5ESS!" Exit Sub End If End If 'list.ListCount > 0 Else 'se non ci sono SM selezionati MsgBox "Devi selezionare almeno un SM!" Exit Sub End If 'Me.flex.Row > 0 MsgBox "SM associati con successo!"Exit SubErrore_ass: MsgBox "Si è verificato un errore all'interno della Sub 'cmdAssocia_Click' nel form 'frmElencoSM'."End Sub

Private Sub cmdElSM_Click() 'elimina un sm, ovvero lo disassocia da tutti gli hts al quale è associatoOn Error GoTo Errore_eDim answer As Integer caricaRSsmEDI If RSsmEDIT.RecordCount > 0 Then If test = True Then answer = MsgBox("Questa operazione eliminera e disassociera l'SM da tutti i 5ESS. Vuoi continuare?", vbYesNo, "Conferma eliminazione KEY") If answer = 6 Then 'se confermiamo RSsmEDIT.MoveLast RSsmEDIT.MoveFirst Do While Not RSsmEDIT.EOF 'cerco il record da eliminare


137

If RSsmEDIT.Fields("SM").Value = Me.flex.Text Then RSsmEDIT.Delete RSsmEDIT.MoveNext Else RSsmEDIT.MoveNext End If Loop visualizzaSM test = False 'setto flex come non cliccato oldCol = 0 oldRow = -1 End If End If End If 'RSsmEDIT.RecordCount > 0 ThenExit SubErrore_el: MsgBox "Si è verificato un errore all'interno della Sub 'cmdElSM_Click' nel form 'frmElencoSM'."End Sub

Private Sub flex_Click()On Error GoTo Errore_flexDim i As Integer test = True With flex 'salvo le coordinate della cella selezionata nowCol = .Col nowRow = .Row 'se esistono le coordinate di una selezione precedente rimetto sfondo bianco If oldRow >= 0 Then' questo For i = 0 To .Cols - 1 .Col = oldCol 'i .Row = oldRow .CellBackColor = oldColor '&H80000005 'bianco' questo Next i End If 'imposto le coordinate correnti ed imposto sfondo giallo 'For i = 0 To .Cols - 1 '.Col = nowCol .Col = nowCol 'i .Row = nowRow 'salvo il colore come old oldColor = .CellBackColor .CellBackColor = &H80FFFF 'giallino 'Next i 'salvo le coordinate correnti come old oldCol = nowCol oldRow = nowRow End WithExit SubErrore_flex: MsgBox "Si è verificato un errore all'interno della Sub 'flex_Click' nel form 'frmElencoSM'."End Sub

Private Sub Form_Load(On Error GoTo Errore_form Left = (Screen.Width - Width) / 2 ' Centra il form orizzontalmente. Top = (Screen.Height - Height) / 2 ' Centra il form verticalmente If Not dbGiaAperto(dbTrendy) Then If Not ApriDatabase(dbTrendy, DBPath & "\" & DBName, False, False, wsTrendy) Then MsgBox "Impossibile aprire il database " & DBPath & "\" & DBName, vbExclamation, glTitolo End End If


138

End If 'caricaRS ' set the module level callback pointer lpFormObj = ObjPtr(Me) SetProp frmElencoSM.hwnd, "PrevWndProc", SetWindowLong(frmElencoSM.hwnd, GWL_WNDPROC, AddressOf WndProcElen-coSM) topRow = 1 visualizza With flex .TextMatrix(0, 0) = "SM" .Row = 0 .Col = 0 .FillStyle = flexFillRepeat .CellFontBold = True .CellAlignment = flexAlignCenterCenter .AllowUserResizing = flexResizeBoth '.ColWidth(0) = 1250 .BackColorBkg = vbWhite 'Background of cellwhen it is selected .BackColorSel = vbYellow 'Forecolor of cell when it is selected .ForeColorSel = vbBlack 'Backcolor of cell when it is unselected '.BackColor = RGB(192, 189, 215) 'Forecolor of cell when it is unselected .ForeColor = vbBlack .GridColor = vbBlack End WithExit SubErrore_form: MsgBox "Si è verificato un errore all'interno della Sub 'form_load' nel form 'frmElencoSM'."End Sub

Public Sub ScrollUp()On Error GoTo Errore_ScrollUp ' scroll up.. If RSsm.RecordCount > 34 Then If topRow > 1 Then topRow = topRow - 1 flex.topRow = topRow End If End IfExit SubErrore_ScrollUp: MsgBox "Si è verificato un errore all'interno della Sub 'ScrollUp' nel form 'frmElencoSM'."End Sub

Public Sub ScrollDown()On Error GoTo Errore_ScrollDown ' scroll down.. If RSsm.RecordCount > 34 Then If topRow < flex.Rows - 1 Then topRow = topRow + 1 flex.topRow = topRow End If End IfExit SubErrore_ScrollDown: MsgBox "Si è verificato un errore all'interno della Sub 'ScrollDown' nel form 'frmElencoSM'."End Sub

Private Sub caricaRS()


139

On Error GoTo Errore_caricaDim sqlHTS As String, sqlSM As String, str1 As String str1 = Crypt("5ESS") sqlHTS = "Select * from ElencoHTS where Tipo= " & Chr(34) & str1 & Chr(34) & " order by HTS" If Not ApriRecordSet(sqlHTS, RShts, dbTrendy, dbOpenDynaset, 0, 0, False) Then MsgBox "Impossibile aprire il recordset: " & sqlHTS & " - " & Errore, vbExclamation, glTitolo Errore = "" Exit Sub End If sqlSM = "Select distinct SM from ElencoSM order by SM" If Not ApriRecordSet(sqlSM, RSsm, dbTrendy, dbOpenDynaset, 0, 0, False) Then MsgBox "Impossibile aprire il recordset: " & sqlSM & " - " & Errore, vbExclamation, glTitolo Errore = "" Exit Sub End IfExit SubErrore_carica: MsgBox "Si è verificato un errore all'interno della Sub 'caricaRS' nel form 'frmElencoSM'."End Sub

Public Sub visualizza()On Error GoTo Errore_visualizza visualizzaSM visualizzaHTSExit SubErrore_visualizza: MsgBox "Si è verificato un errore all'interno della Sub 'visualizza' nel form 'frmElencoSM'."End Sub

Public Sub visualizzaHTS() 'visualizza gli hts nella listboxOn Error GoTo Errore_visualizzaHTSDim X As Integer, vett() As String, j As Integer, i As Integer, temp As String If RShts.RecordCount > 0 Then RShts.MoveLast RShts.MoveFirst X = RShts.RecordCount ReDim vett(X) ''''''''''''riempio il vettore dei 5ESS RShts.MoveFirst For j = 1 To RShts.RecordCount vett(j) = DeCrypt(RShts.Fields("HTS").Value) RShts.MoveNext Next '''''''''''''ordino il vettore For i = 1 To X - 1 For j = i + 1 To X If StrComp(UCase(vett(i)), UCase(vett(j)), 1) = 1 Then temp = vett(i) vett(i) = vett(j) vett(j) = temp End If Next Next ''''''''''''riempio la listbox i = 1 RShts.MoveFirst Do While Not RShts.EOF list.AddItem (vett(i)) i = i + 1 RShts.MoveNext Loop End If


140

Exit SubErrore_visualizzaHTS: MsgBox "Si è verificato un errore all'interno della Sub 'visualizzaHTS' nel form 'frmElencoSM'."End Sub

Public Sub visualizzaSM() 'visualizza gli sm nella flexgridOn Error GoTo Errore_visDim i As Integer, color As Boolean caricaRS If RSsm.RecordCount > 0 Then ''''''''''' riempio la flex grid RSsm.MoveLast RSsm.MoveFirst flex.Rows = RSsm.RecordCount + 1 color = True i = 1 If RSsm.RecordCount < 35 Then flex.ColWidth(0) = 1250 Else flex.ColWidth(0) = 950 End If Do While Not RSsm.EOF flex.TextMatrix(i, 0) = RSsm.Fields("SM").Value flex.Row = i flex.Col = 0 If color = True Then flex.CellBackColor = &H80000009 Else flex.CellBackColor = &H8000000F End If flex.CellAlignment = flexAlignCenterCenter color = Not color RSsm.MoveNext i = i + 1 Loop Else 'RSsm.RecordCount > 0 flex.Rows = 2 flex.TextMatrix(1, 0) = "" End IfExit SubErrore_vis: MsgBox "Si è verificato un errore all'interno della Sub 'visualizzaSM' nel form 'frmElencoSM'."End Sub

Private Sub cmdSelAll_Click() 'seleziona tutti gli SMOn Error GoTo Errore_selallDim i As Integer For i = 0 To list.ListCount - 1 list.Selected(i) = True Next iExit SubErrore_selall: MsgBox "Si è verificato un errore all'interno della Sub 'cmdSelAll_Click' nel form 'frmElencoSM'."End Sub

Private Sub cmdDeSelAll_Click() ' deseleziona tutti gli SMOn Error GoTo Errore_deselallDim i As Integer For i = 0 To list.ListCount - 1 list.Selected(i) = False Next iExit Sub


141

Errore_deselall: MsgBox "Si è verificato un errore all'interno della Sub 'cmdDeSelAll_Click' nel form 'frmElencoSM'."End Sub


142

STUDY OF NETWORK NODES RELIABILITY …teca.elis.org/7178/INGALLO.pdf · STUDY OF NETWORK NODES...

Documents

Transcript of STUDY OF NETWORK NODES RELIABILITY …teca.elis.org/7178/INGALLO.pdf · STUDY OF NETWORK NODES...