Roaming Java Services

8/7/2019 Roaming Java Services

1/102

Eindhoven University of TechnologyDepartment of Electrical EngineeringInformation- and Communication Systems GroupP.O. Box 5135600 MB EindhovenThe Netherlands

Ericsson Telecommunications B.V.Business creation & Applied research CompanyP.O. Box 85120 AA RijenThe Netherlands

Roaming Java Servicesfor Intelligent Networks

J.R. Derikx

Graduation Report

Rijen, August 1999

Coaches:

Profjr. J. de Stigter (TUE)ir. J. van der Meer (Ericsson)

Th e Faculty of Electrical Engineering of th e Eindhoven University of Technology does no taccept any responsibility regarding the contents of student projects an d graduation reports.


2/102

Preface

Th e report before you was written as part of my final project of th e Information Technologystudies at the Eindhoven University of Technology. The project was carried ou t at the Businesscreation & Applied research Company (BAC) which is part of th e R&D business line of Ericsson

Telecommunication B.V. in Rijen. It was carried ou t from November 1998 until August 1999.During the first part of this project I researched th e possibilities of mobile code, the securityinvolved and how to integrate the concept in an Intelligent Network. During th e second part Ideveloped and implemented a prototype system. The project gave me th e opportunity to learnmany new things like ERLANG , IN, Java and UML, and how to apply these to create a prototype.\Vorking in a large company like Ericsson gave me a chance to closely observe how fast th e telecommarket is changing and how rapidly companies will have to adapt to these changes. I enjoyed thesenine months at BAC and am convinced that it was a valuable experience.

I would like to thank my coaches, Prof.ir. J. de Stigter and ir. J. van der Meer for giving methe opportunity to do this project, their guidance and useful comments. Furthermore I would like

to thank my colleagues at BAC for making me feel at home, for their advice and help. Specialthanks to Erik van der Velden and Eltjo Boersma for their input and help with ErlangjRSP andJava. I thank my friends and roommates for th e good times we had in th e past years. Finally, Iwould like to thank my parents who always stood by me and gave me their full support. Thankyou all!

Bertho DerikxAugust 1999

ERICSSON


3/102


4/102

Roaming Java Services fo r Intelligent Networks

be used for the prototype. Java RMI provides th e communication between the JS E and IN servernode.

Th e prototype is operationaL When a subscriber registers in a network, detect ion points are

transferred from the IN server to the JSB. These detection points are installed in th e SSF whena call is initiated. When th e subscriber triggers an IN service, th e service is downloaded from theIN server by the JSE and executed locally. The detection points and IN services are cached in theJS E while th e subscriber remains registered in the network.

Java does not provide explicit means to unload classes. Th e use of RMI makes this process evenmore difficult. I t remains unclear whether Java is able to reliably unload classes. RMI itself alsohas several disadvantages that justify research on other communication protocols. It also remainsunclear how Java will perform on a heavily loaded system. Because th e prototype uses th e localnetwork, it is not possible to determine how much th e transport delays would increase in a realnetwork. These subjects are left for further study.

iv ERICSSON


5/102

Contents

Preface

Summary

1 Introduct ion

1.1 Scope of th e Project

1.2 Problem Definition

1.3 Report Outline

2 Backgrounds

2.1 An Introduction to Intelligent Networks2.2 An Introducti on to CAMEL.

2.3 An Introduction to Java . . .2.4 An Introducti on to Erlang and Jive.

2.5 An Introducti on to Rapid Service Prototyping .

3 Mobile Code

3.1 Mobile code . . . . . . . . .3.2 Roaming Services in an IN .

3.3 Java and mobile code . . .3.3.1 Custom Class Loaders

3.3.2 Object Serialization

3.3.3 Java Remote Method Invocation

3.3.4 Java IDL

3.3.5 RMI-IIOP.

3.4 Summary . . .

4 Security Aspects

4.1 Security an d mobile code

4.2 Host security . . . . . . .

ERICSSON

iii

1

1

2

2

5

59

11

12

14

1515

17

17

17

18

18

20

20

21

23

23

23

v


6/102


4.3 Service security .

4.4 Java and security

4.4.1 Th e JDK 1.2 Security Model

4.4.2 Java security applied to mobile code

4.5 Summary . . . . .

5 Roaming IN Services

6

5.1 Roaming Services in an IN .

5.1.1 Tracking th e subscriber

5.1.2 Arming Detection Points

5.1.3 Retrieving and Invoking IN Services

5.2 Service Management .

5.3 Services and mobility.

5.4 Th e Virtual Private Network Service

5.5 Summary . . . .

R JS System Design

6.1

6.2

6.3

6.4

Th e RJ S system

Th eServer Node

6.2.1 Use Case Diagram

6.2.2 Class Diagram ..Th e Java Service Environment Node


6.3.2 Class Diagram ..Th e Service Control Function Node.


6.4.2 Class Diagram

6.5 IN Services . . . . . .

6.6 A Single.-threaded vs. Multi-threaded Implementat ion

6.7 Summary . . . .

7 The R JS Proto type

7.1 Th e RJ S System

vi

7.2 Th e Service Control Function

7.3 Th e Java Service Environment

7.3.1 Singletons in Java . . .7.3.2 Th e ScfGateway and th e SSFList classes.

7.3.3 Th e SSF, the SSFInterface and th e CallList classes.

ERICSSON

24

25

25

28

28

29

29

30

30

30

32

33

33

34

35

35

35

35

38

38

38

39

43

43

43

43

44

45

47

47

48

49

49

49

50


7/102

7.3.4 Th e JobHandler, the Queue an d Job classes.

7.3.5 Th e Call class . . . . . . . . . . . . . . . . .7.3.6 Th e ServerGateway and ServerThread class

7.3.7 The Cache class

7.4 The IN Server. . . . . .

7.4.1 Th e Server Package

7.4.2 The Subscriber package

7.4.3 The Service Package . .7.4.4 The JS E Manager package

7.5 Interfaces . . . . . . . . . . . . .

7.5.1 The SCF - JSE interface.7.5.2 Th e IN Server - JS E interface .

7.6 IN Services . . .

7.7 Common Classes

7.8 Limitations of the prototype.

7.8.1 The IN Server

7.8.2 The JSE ..7.9 Unloading classes.

7.10 Service Interworking

7.11 Summary . . . . . .

8 Conclusions

8.1 Problem Definition

8.2 Architecture of the RJ S system

8.3 Security Aspects . .

8.4 The RJS prototype .

8.5 A monopolistic environment.

8.6 Recommendations for future work

A The Basic Call State Model

A.1 Th e Originating Basic Call State Model

A.2 Th e Terminating Basic Call State Model .

A.3 RSP Originating Basic Call Model .

A.4 RSP Terminating Basic Call Model .

B Information Flows

B.1 Information Flows in the RSP .

B.2 Information Flows in the roaming IN services architecture

ERICSSON

CONTENTS

51

51

51

52

53

53

54

54

55

55

55

56

58

59

60

60

60

61

61

62

63

63

63

64

64

65

66

67

67

68

70

71

73

73

74

vi i


8/102


B.2.1 IFs between th e SSF and the SCF

B.2.2 IFs between th e SCF and th e SE .

B.2.3 IFs between th e SE and the IN server

B.2.4 IFs between th e SE and the local cache

B.3 Standardized Information Flows.

C Activity Diagrams

C.1 Th e Server Node

C.2 Th e Java Service Environment Node

D Sequence Diagrams

E User Manual

E.1 Compiling th e IN Server and the JSE .....E.l.1 Th e se.ericcson.etm.rjs.common package

E.l.2 Th e se.ericsson.etm.rjs.cache package.

E.l.3 Th e IN Server

E.l.4 Th e JS E . . .E.2 Th e IN Server G UI .

E.2.1 The JSE GUI .E.3 Th e RSP-software . .E.4 Using prototype services

Acronyms

Bibliography

viii ERICSSON ;e:

74

74

74

75

75

77

77

80

83

87

87

87

88

88

88

89

91

92

92

95

97


9/102


10/102

Java Services for Networks

HOME VISITED

Figure 1.1: Access by means of a signaling connection, two vari ants

.....

HOME . / .............. VISITED................... -

1.2: Th e IN service is moved to the visited SCF

1. 2 Problem Definition

What is known about th e mobile code concept an d can it be applied to the IN architecture? Hasit already been used and what are its advantages and disadvantages?

Code-fragments an d data will have to be transferred to another execution environment. Thisraises major security issues. How to protect th e host, th e IN service and the data? An d can th eprivacy of th e subscriber be guaranteed?

Java is relatively new and still under development. Is this programming language capable ofsatisfying th e necessary security requirements an d how does it implement code-mobility?

This project comprises of two phases. Th e first phase will try to find answers to the questionsraised above. In th e second phase a prototype will be designed and implemented. Th e prototype

will implement a to be developed "roaming Java IN services" architecture.

1.3 Report Outline

This section gives a brief survey of th e remaining chapters of th e report.

Chapter 2 gives an introduction to some basic concepts that will be used in th e report. Th e nexttopics will be discussed:

Intelligent Networks

CAMEL Java Rapid Service Prototyping Erlang an d Jive

Readers already familiar with a concept can skip th e appropriate section.

2 ERICSSON


11/102


12/102

Chapter 2

Backgrounds

The chapter Backgrounds introduces to th e reader the concepts and technologies usedduring the project. It starts with an introduction to Intelligent Networks followed bya description of Sun's programming language Java T M . Th e last two sections deal withth e programming language Erlang and th e Rapid Service Prototyping software used forprototyping.

2.1 An Introduction to Intelligent Networks

The concept of intelligent networks (IN) boomed in th e mid-eighties after the US telecommunications monopoly was broken. 1 The goal of the intelligent network concept was and is toreduce the time-to-market of new services. This is accomplished by the introduction of reusablebuilding blocks and a network-implementation-independent provisioning of services. Th e networkintelligence has been separated from the switching function.

Th e International Telecommunication Union (ITU) has defined a standardized model for intelligentnetworks in the Intelligent Networks Recommendations (Q-series): the IN Conceptual Model(INCM) [33:. Capability Set 1 (CS-l) is th e first standardized stage of the Intelligent Networkarchitecture [34].

The INCM model, depicted in figure 2.1, represents the IN at four different abstraction levelscalled planes:

The service plane (Q.1202) The global functional plane (GFP) (Q.1203) The distributed functional plane (DFP) (Q.1204) The physical plane (Q.1205)

The service plane models the IN as a set of services. A service is characterized by its servicefeatures (SFs). The service plane gives no information whatsoever about the implementation ofservices in the network. An example of a service is the "Premium Rate" service. Callers payan extra fee which will be forwarded by the network operator to the called party. Some of thisservice's features are "Premium Charging", "One Number", "Call queueing" and "Call logging" .

The next step is to model the IN as one big entity. The global functional plane shows that servicefeatures are pu t together from service independent building blocks (SIBs). Each block performsa specific function and can be reused for multiple services. Service logic glues the building blocks

1 In January 1984 Bell System, forced by th e U.S. government, split up in one long-distance carrier an d sevenregional telephone holding companies.

ERICSSON 5


13/102

Roaming Java Services fo r Inte l l igent Networks

6

~~ervice 1

EJ

... ..-.. ....

" .~ ' .

POI----JIo.....-

POR

Service 2

Service Plane

Global Functional Plane

FE2Distributed Fuhctional Plane

. ..

P E Q \ @ E 2 FE3FE1

PE2

Physical Plane

Figure 2.1: The IN conceptual model

ERICSSON


14/102

Chapter 2. Backgrounds

together. There is one special building block that handles the Basic Call Process (BOP). Thisblock is connected to th e chains of SIBs by points of initiat ion (POI) and points of return (POR).Refer to figure 2.2. The "Limit"-block is an example of a building block. I t makes sure that thenumber of calls that pass through does not exceed a parameter specified by th e operator. Th enumber of calls per minute should, for instance, not exceed x.

Figure 2.2: A service is created by gluing SIBs together

In th e distributed functional plane, th e IN is divided in unique groups of functions called functionalentities (FEs). Each functional entity performs a number of functional entity actions (FEAs).The functional entities communicate through information flows (IFs). Figure 2.3 shows a typicalfunctional model diagram containing the following entities:

Call control agent function (CCAF) - This function handles the subscriber access to th enetwork. I t is found in local exchanges.

Call control function (CCF) - The CCF handles th e call processing and control. It alsoprovides a trigger mechanism to access IN functions.

Service switching function (SSF) - This function handles th e communication between a CCFand the SCF.

Service control function (SCF) - The SCF function is th e heart of the IN network. It containsth e centralized intelligence of the network.

Service data function (SDF) - The SDF contains subscriber and network data which can beaccessed by the SCF.

Specialized resource function (SRF) - The SRF provides specialized resources needed by theIN services. I t is used to send and receive data to an d from subscribers.

Service creation environment function (SCEF) This function handles defining, developingand testing of IN services and their transportation to th e S::v1F.

Service management agent function (SMAF) This function handles th e operator provideraccess to th e network.

Service management function (SMF) - Th e SMF manages th e distribution, the control and

th e maintenance of IN services.

Figure 2.3: The distributed functional plane model

In the physical plane the functional entities are mapped to physical entities (PE). The mappingis shown in table 2.1.

ERICSSON 7


15/102


Physical enti ty Functional enti tyService switching point (SSP) SSF and CCFService control point (SCP) SCFService data point (SDP) SDFIntelligent peripheral (IP) SRFAdjunct (AD) SCF an d SDFService node (SN) SSF, CCF, SCF, SDF and SR F

. Service switching and control point ( S S S ~ ? lSSF, CCF, SCF, SD FService management point (SMP)

P s FService creation environment point (SCEP) EFService management access point (SMAP) SMAF

Table 2.1: Mapping functional entities to physical entities

In th e DFP, the Basic Call State Model is introduced. The Basic Call State Model (BCSM) is ahigh level finite state machine description of call processing for basic call control. A basic call is atwo party non-IN call. The components of the BCSM are shown in figure 2.4. A state of the FSMis called a Point In Call (PIC). A Detection Point (DP) is a point in the basic call processing atwhich an event may be reported to an SCF an d transfer of processing control may occur. POlsthat are introduced in th e GFP, are mapped to DPs in the DFP. Refer to Appendix A for theOriginating and Terminating BCSM.

l ~ ~ T r . n S i t i o n

_ _ --'.I_D_Pi

[ ___ I.,--Ci

Figure 2.4: BCSM components

Detection Points are points in th e BCP at which an IN service may be invoked. DPs are characterized by four attributes:

8

Arming/disarming mechanism - A DP can be statically armed or dynamically armed. DP sare armed statically through the SMF service feature provisioning. When armed statically,the DP is referred to as a Trigger Detection Point (TDP). A TD P can only be disarmed bythe SMF. The SCP is able to dynamically arm a DP. A dynamically armed DP is called anEvent Detection Point (EDP). An ED P is disarmed when triggered.

Criteria - When an armed DP is encountered, the SCF is notified only when the additionalDP Criteria are met.

Relationship When an armed DP is encountered and the criteria are met, the SSF CCFestablishes a relationship with the SCF. Two types exist In a control relationship the SCFis able to influence call processing via th e relationship and in a monitor relationship the SCFin no t able to influence call processing via the relationship.

Call processing suspension - Call processing mayor may not suspended to allow the SCFto influence the subsequent call processing. This only applies for a control relationship.

ERICSSON ;:!


16/102

Chapter 2 . Backgrounds

In the past, the intelligence of th e network resided in th e individual local exchanges. Introducing anew service was time-consuming and difficult; it took two to five years. The goal of th e intelligentnetwork concept is to reduce this to less than six months. therefore th e service logic was movedto a centralized location: the service control point.

In today' s mobile world, subscribers roam. Unfortunately, they lose the ir IN services when theymove beyond th e service area of their home SCPo One possible solution to is to set up a signalingconnection to th e home SCPo For th e GSM network for instance, the ETSI has defined a standardcalled Customized Applications for Mobile network Enhanced Logic (CAMEL). Refer to section 2.2for more information on CAMEL. A second solution is to move th e subscriber's service profile toth e visited network's SCPo The service profile should contain th e subscriber's customized servicesand the related detection points.

2.2 An Introduction to CAMEL

In th e past, when subscribers traveled beyond the boundaries of their home GSM network, mostof their services were no longer accessible. Only a few standardized GSM services could be used.Nowadays operators try to differentiate themselves by offering their clients value-added customizedservices. ETSI has developed a standard, CAMEL2 [2], that gives operators th e opportunity tooffer Operator-Specific Services (OSS) outside their own networks. CAMEL can be seen as th eintegration of IN into th e GSM architecture.

Figure 2.5 depicts the functional entities in the CAMEL (phase 1) supporting GSM Network.When a roaming subscriber accesses one of his IN services, a signaling connection is establishedbetween th e gsmSSF and the gsmSCF. Th e IN service is executed in th e gsmSCF and the result

is returned to th e gsmSSF.

Interrogating Network Visited Network

Figure 2.5: The Functional Architecture for support of CAMEL

The Home Location Register (HLR) stores all th e administrative information of each subscriberregistered in GSM network, th e current location of th e mobile equipment and the Originating andTerminating CAMEL Subscription Information (O-CSI and T-CSI).The Visitor Location Register (VLR) stores selected information from th e HLR, among which theO-CSI, for each subscriber currently in its service area.The Mobile ser'Vices Switching Center (MSC) acts like a switching node bu t additionally providesall th e functionality needed to handle a mobile subscriber.The Gateway M Sc (GMSC) is an MSC that also contains a tab le that links the subscriber's phonenumber to his corresponding HLR.The gsmScF contains th e CAMEL service logic that implements th e OSS.The gsmSSF interfaces the MSCjGMSC to the gsmSCF.

For every subscriber that uses CAMEL services the HLR contains both originating and terminatingCAMEL subscription information. The O-CSI applies to those CAMEL services available when

section describes CAMEL phase 1 only.

ERICSSON 9


17/102


th e subscriber makes th e call: a mobile originated call. Th e T-CSI is used when th e subscriber isbeing called: a mobile terminated call. Th e CSI contains four data fields:

Th e gsmSCF address is used to access th e gsmSCF of a particular subscriber.

Th e Se'&Vice

Key identifies th e service logic to th e gsmSCF. Th e Default Call Handling indicates whether th e call should be released or continued aftera communications error between the gsmSCF an d gsmSSF.

Th e Trigger Detection Point list indicates on which detection points triggering shall takeplace, i.e. afte r which events in th e call process th e MSC notifies th e gsmSCF.

When a CAMEL subscriber switches his mobile phone on in a new location area or moves to anew location area or other network, it registers with th e network to update it s current location.Th e visited MSCjVLR notifies th e home HL R which responds by sending th e previously mentioned subset of subscriber information, including th e O-CSI, to the visited MSCjVLR. The oldMSCjVLR is notified by th e HL R to cancel th e old registration. Refer to figure 2.6.

Figure 2.6: Location Update

Th e Trigger Detection Point list is part of th e CSI. When th e CSI is sent to the MSC, th e listedDP s are armed for that subscriber. When th e BCSM reaches an armed DP an d th e criteria aremet, control is transferred to the gsmSCF. For th e O-CSI only DP2, and for th e T-CSI only DP12is used. Note that CAMEL.also supports th e following EDPs: DP7, DP9, DP15, DP17. Theseca n be installed by th e SCPo (Refer to Appendix A for an explanation of th e DPs.)

CAMEL differentiates between a mobile originated call, a mobile terminating call an d call forwarding. Refer to figure 2.7, figure 2.8 an d figure 2.9.

8 Home Network\

ontinue, Connect, ReleaseCall. . . . . . . . . . . . . . . . . . . . . . . . .\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .InitialDP

Visited Network

Figure 2.7: Mobile originated call setup

Mobile Originated Call:When, during call setup, th e O-CSI is found in the VLR for th e A-subscriber, th e visited SSFwill send th e ln i t i a lDetec t ionPoin t message to the gsmSCF an d suspend th e call processingif a detection point is triggered. Th e message contains th e Service Key which unambiguouslyidentifies th e requested CAMEL service to th e gsmSCF. Th e gsmSCF processes th e appropriateservice logic and, depending on th e outcome, returns th e Connect, Continue or ReleaseCallmessage. Th e gsmSSF then takes th e indicated course of action.

10 ERICSSON as


18/102

Chapter 2. Backgrounds

Home Network ~ ~~ InitialDP ~s e n d R ~ ~ i ; n g l n i ~ ! f . : r - C . ~ . I... ~ u ; ; , c o n ~ ~ c t , R ~ I ~ ~ ~ e C a l l

!I(QSmSSF j . . : I ~I n C ~ i I ' " g .GSMC : ~

Interrogating Network : 0 VISited Netwoll 1

AnalyseJnfo.

Route_Select_Failure

Routing & Alerting

Figure A.l: The Originating BCSM for CS-l

ERICSSON 67


74/102


O_Null & Authorize_Origination-Attempt:The line/trunk is idle. When th e originating party tries to place an outgoing call (e.g. phoneoff-hook) his authority/ability is verified.

D P 1 Origination Attempt-Authorized:Th e originating party is trying to place a call and th e authority/ability to do so has been verified.

Collect Jn fo rma t on:The initial information string is being collected from th e originating party.

D P 2 Collected_Information:The complete initial information string is available from the originating party.

Analyse_Information:The information is analysed and/or translated according to the dialling plan in order to determineth e routing address an d call type.

D P 3 Analysed_Information:The routing address and its nature is available.

Routing & Alerting:The routing address an d call type are interpreted, the authority of the originating party to placethis call is verified and th e call is processed by the T-BCSM.

D P 4 Route_Select-Failure:All routes are busy.

D P 5 O_Called_Party_Busy:The terminating side is busy.

D P 6 O_No-Answer:

The terminating side does not answer.D P 7 O_Answer:The call is accepted and answered by the terminating party.

O_Active:The connection between the originating and terminating party has been established.

D P 8 O_Mid_Cal1:A service feature request is received from th e originating party.

O_Exception:An exception has occured and is now being handled.

D P 9 O...Disconnect:One of th e parties has disconnected th e call.

D P 10 O_Abandon:The call is abandoned before a connection could be established.

A.2 The Terminating Basic Call State Model

Figure A.2 shows the Terminating BCSM according to the ITU standards. Th e numbered squaresrepresent DPs and the blocks represent PICs.

T_Null & Authorize_Terminat ion-Attempt:The line/trunk is idle. When an incoming call arrives, the authority/ability of th e terminatingparty is verified.

68 ERICSSON


75/102

Appendix A. The Basic Call State Model

T_Disconnect

Figure A.2: Th e Terminating BCSM for CS-l

D P 12 Termination_AttempL Verified:An indication for an incoming call is received an d th e terminating party's authority ability isverfied.

SelecLFacility & PresenLCall:Select an available resource from th e resource group and inform th e terminating party of anincoming call.

D P 13 T _Called_Party -Busy:Th e terminating party is busy.

T _Alerting:Waiting for th e call to be answerd by th e terminating party. Th e originating party is informedthat the terminating party is being alerted.

D P 14 T _No_Answer:Th e ringing timer has expired before th e terminating party answered.

D P 15 T _Answer:Th e call is accepted an d answered by th e terminating party.

T_Active:Th e connection between th e originating and terminating party has been established.

D P 16 T _Mid_Call:A service feature request is received from th e terminating party.

T _Exception:

An exception has occured an d is now being handled.D P 17 T _Disconnect:One of the parties has has disconnected th e call.

D P 10 T _Abandon :Th e call is abandoned before a connection could be established.

ERICSSON s: 69


76/102


77/102

Appendix A. The Basic Call Sta te Model

call_proceeding:Set up the call to the terminating side.

waiting_for _answer:

Wait for the Address Complete message from th e other side.active:A speech connection between the originating and the terminating party is established.

midcall:A hookflash is received.

release_pending:Th e terminating subscriber has terminated. \Vait for re-answer or disconnection of the originatingside.

exception:

A fault occured.disconnect:The originating side disconnected.

A.4 RSP Terminating Basic Call Model

Figure A.4 shows the Terminating BCM as implemented by the RSP software. I t was taken from[10].

I t_ disconnect r ~ Cexception II Cnull I

IL

auth_termination I

I~

hunting_facilitybusyl10t

~ received

I presenting3ali call~ rejected

alerting

~ringingtimeout

I Cactive I~ T

I '-release_pending IFigure A.4: Th e Terminating BCM for the RSP software

Lnull:Start of call.

auth_termination:Check if the call is allowed to terminate.

ERICSSON 71


78/102


hunting_facility:Select an outgoing device.

presenting_call:

Offerth e

callto th e

outgoing side.alerting:Th e outgoing side is being alerted, wait for answer.

t_active:A speech connection between the originating and the terminating party is established.

t_release_pending:One of the parties has terminated. Wait for the other party to terminate as welL

t _exception:A fault occurred.

t_disconnect:Th e call is disconnected.

72 ERICSSON


79/102

Appendix B

Information Flows

B.I Information Flows in the RSP

This section describes the information flows between the SCF node and the SSF node in th e RSP(refer to section 2.5).

Messages from th e SSF to the SCF:

"initiate" Initiates the communication session between the SSF and SCF. "simulation end" - Terminates th e communication session between th e SSF and SCF. The

SCF should respond with "simulation ended" . "provide" Indicates that a static breakpoint has been triggered. "event" Indicates that a dynamic breakpoint has been triggered.

Messages from the SCF to the SSF:

"update breakpoint set" - Set a static breakpoint in th e SSF. "update breakpoint unset" - Unset a static breakpoint in th e SSF. "update analysis set" - Add a telephone number (one or more) to the number analysis set. "update analysis unset" - Remove a telephone number (one or more) from th e number

analysis set. "create" Create a call (a virtual call) with th e given service data. "register" - Register a subscriber on th e given telephone set. "un Unregisters a subscriber. "l ineMonitor" Perform a linemonitor on th e given telephone set. "load data" Substitute the call data by th e provided new call data. "set monitor" Set a dynamic breakpoint in th e SSF. "unset monitor" Unset a dynamic breakpoint in th e SSF. "transfer" Request the SSF to terminate communications. The SSF will respond with

"simulation end" .

"continue" Tells th e SSF to continue with the next state in the call state modeL

"message" Display specified message on the telephone's display. "input" Prompt the user for information. "scf inte rrupt" Force the call to the state "scf interrupt" . The SCF takes immediate control

of th e calL

Refer to [10] for the detailed message syntax.

ERICSSON ; ; 73


80/102

Java Services fo r Networks

B.2 Information Flows in the roaming IN services architec-

ture

This section describes the information flows (IF) in th e roaming IN services architecture as presented in chapter 5.

B.2.! IFs between th e SSF and th e SC F

IFs originating from the SSF are:

Registrat ion message - Th e mobile terminal tries to register with th e network. DPl/DP12 triggered - Either DPI or DP12 has been triggered. Th e EDPs need to be

armed. ED P triggered - An ED P has been triggered indicating tha t a roaming IN service is re

quested. Standardized IFs as described in Recommendation Q.1214 section 6.4 [34J.

See also section B.3.

IFs originating from the SCF are:

Standardized IFs as described in Recommendation Q.1214 section 6.4 [34].See also section B.3.

B.2.2 IFs between th e SCF and th e SE

IFs originating from the SCF are:

Registration message - Th e mobile phone tries to register with the network. DPl/DP12 triggered Th e SCF requests the subscriber's DPL. ED P triggered - An EDP has been triggered indicating tha t a roaming IN service is re

quested. Standardized IFs as described in Recommendation Q.1214 section 6.4 [34].

See also section B.3.

IFs originating from the SE are:

DP L available Th e SE passes th e subscriber's DP L to the SCF.

Standardized IFs as described in Recommendation Q.1214 section 6.4 [34]. See also sectionB.3.

B.2.3 IFs between th e SE and th e IN server

IFs originating from the are:

Registrat ion message Th e SE requests th e subscriber's DPL. Request IN service Th e SE requests a roaming IN service.

IFs originating from the IN server are:

74

Registration response Th e server returns either th e subscriber's DP L or a Negative Ac-knowledgement (NACK).

IN service Th e server returns the requested IN service or a NACK. Remove DPL The server instructs the SE to remove one or more DPLs from the local

cache.

ERICSSON ;;5


81/102


82/102

Appendix C

Activity Diagrams

C .l The Server Node

Figure C.l: Activity diagram of th e "Manage Subscribers" use case

ERICSSON iii 77


83/102

Roaming Java Services for Intelligent Networks

Figure C.2: Activity diagram of th e "Manage IN Services" use case

Figure C.3: Activity diagram of the "Publish DPLs" use case

78 ERICSSON


84/102

Appendix C. Activity Diagrams

Figure C.4: Activity diagram of the "Publish IN Services" use case

Figure C.5: Activity diagram of the "Manage JS E Access" use case

ERICSSON it! 79


85/102


C.2 The Java Service Environment Node

Figure C.6: Activity diagram of the "Manage Cache" use case

Figure C.7: Activity diagram of th e "Register Subscriber" use case

80 ERICSSON


86/102

Appendix C. Activity Diagrams

Figure C.8: activity Diagram of the "Arm Dectection Points" use case

Figure C.9: Activity diagram of the "Invoke IN Service" use case

ERICSSON 81


87/102

Appendix D

Sequence Diagrams

The following pages show the sequence diagrams for th e Java Service Environment. Th e firstdiagram shows th e actions taken in the JSE when a subscriber registers with th e network. Th esecond shows the actions as th e subscriber goes off hook (DPI is triggered) an d as a call for asubscriber registered in this network comes in (DP12 is triggered). The third sequence diagramshows what happens when a subscriber invokes a roaming IN service.

ERICSSON :i! 83


88/102


~

r

-

' l i ~

03"0..:::;c

~5

I

I

I

~~ .

@

!

J1QilJ

IFigure D.l: Sequence diagram for registering a subscriber

84 ERICSSON i !


89/102

I

- " " i " I " ' m ) ! t a d d ( ~ = " . ~ ) j

:JobHandler

notify() ---- _ II -firslElemenlO

[f-------iob2----------I

e x e c u t e 0 l -

I handleEventO

I i .irslElementOj L~ ' ~ ~ Y - - " ' - ' - I~ i l i li

ca!l1:Call

- - - - - - - ~ - ~ ~ ~ ~ I ~ ~ - - - - - - 1 )

I

I

\\\:2oInInVtiw


90/102

I I

I [ } - 'x e c U I e ( ) ~~ etService gelServlce'. - - l " ' : : ~ " O ;: ~ " " " ):' ' ~ " . " )

i< )( I II

~ f i r s I E l e m e n t ( ~____U---------emPIY,---

I

,-------------- -- --------, -------------["-------nOlifyO

I

e x e c u t e ( ) - ~ h a n d l e E v e n t O ~______, ,I Not shown oIn

Gel service Ir- - cache and

I connectlconhnue

._ ......L ................_ ..... ~ = : : r : : : . . II

rr--firSIElemenlO --

Lf---------emp(y,----- wailO

( r m i ) , ]

"". ',," .....-----------service,,----- I


91/102

Appendix E

User Manual

The RJS package consists of three individual programs:

th e IN Server, th e Java Service Environment (JSE) and th e RSP software.

To work correctly, th e JSE has to be started after th e IN Server and th e RSP software.How these programs are compiled, started and used, is described in th e next sections.

E .l Compiling the IN Server and the JSE

To compile th e IN Server an d th e JSE, one requires JD K 1.2. Th e directory where th e Java 1.2binaries are located will be referred to as .

The JSE depends on th e Jive package which is part of th e Erlang 47.4.1 libraries. Th e directorywhere th e Jive class files can be found will be referred to as . Usually this is th el i b / j i ve -1 .2 /p r iv / j i ve / e r l ang directory found in th e Erlang root directory.

Th e directory where th e IN Server source files can be found will be referred to as .Th e directory where th e JS E source files can be found will be referred to as .

Th e host th e IN Server is running on also needs to run a web server. On this web server th e IN

Server can make it s service class files available for th e JSEs. The directory where th e web serverstores th e class files is referred to as . Th e UR L from which th e JSEs may downloadthese class files is referred to as .

Since th e IN Server an d JS E are mutually dependent, compiling both packages is no t trivial. Tocompile both packages follow th e next steps:

Compile an d distribute th e se.ericsson.etm.rjs.common package. Compile th e se.ericsson.etm.rjs.cache package and distribute th e cache stub files. Compile th e IN Server an d distribute th e server stub files. Compile th e JSE.

E.1.1 The se.ericcson.etm.rjs.common package

Th e common package is part of th e IN Server. Apart from the stub files, it contains those filesthat will be used by both the IN Server an d th e JSE. To compile th e common package, first setth e CLASSPATH environment variable to the . Now go to th e an d run:

ERICSSON i i 87


92/102


/javac se/ericsson/etm/rjs/common/ . java

To distribute th e common package copy th e files in th e directory/se/ericsson/etm/rjs/common

to/se/ericsson/etm/rjs/common.

E.1.2 The se.ericsson.etm.rjs.cache package

Th e cache package is part of the JSE. To compile th e cache package, first se t th e CLASSPATHvariable to th e . Go to the directory and run:/javac se/ericsson/etm/rjs /cache/ . javaTo create th e cache stub files run:/rmic -v l .2 - d . se.er icsson.etm.r js .cache.CacheImpl

To distribute th e cache stub files copy the/se/er icsson/etm/rjs /cache/Cache.class and/se/er icsson/etm/r js /cache/CacheImplJ3tub.class files to/se/er icsson/etm/rjs /cache.

E.1.3 The IN Server

In th e /se/er icsson/etm/rjs /server/Configurat ion file several configurationsettings can be customized:

Th e GUI constant defines whether the GUI should be displayed or not. Th e DEFAULTLOCATION constant sets th e name of th e home network. Th e RMLREGISTRY --PORT sets th e port on which th e RMI registry will be started.

I t is no t necessary to set the'host IP address at which the RMI registry will start. This is alwaysthe IP address of th e host th e IN Server is running on.

Before the IN Server can be compiled th e JAVAROOT an d WWWROOT variables in the/compileserver file have to be edited, so that they reflect the location of respec-tively th e Java compiler j avabin and th e web server root webdi r . Running compileserverwill compile the IN server source files and make the service class files available at the web server.

To distribute the server stub files copy the/se/ericsson/etm/rjs /server/Publisher.classand/se/er icsson/etm/r js /server/Publisherlmpl_Stub. c lass files to/se/ericsson/etm/rjs /server.

E.1.4 The JSE

the /se/ericsson/etm/rjs / jse/Configurat ion files contains several parameters thatcan be customized:

88

Th e JSLIDENTIFICATION constant stores the name of th e JS E and is used to gain access to

the IN Server. Th e JSE_PASSWORO constant stores the password of the JSE and is used to gain access to the

IN Server. Th e GUI constant defines whether the GUI should be displayed or not. The DEBUG constant defines whether additional debug windows should be displayed or not.

ERICSSON


93/102

Appendix E. User Manual

The RMLREGISTRY _IPADDRESS holds the IP address of th e RMI registry. This is the IPaddress of th e IN server.

Th e RMLREGISTRY -PORT holds the port number of th e RMI registry. I t must match th e

setting in th e IN Server configuration file. The JIVE_SERVER_IPADDRESS sets th e IP address of the host th e Jive server is running on. Th e ESCAPE....NUMBER defines the telephone number that activates th e escape service. This is

th e IP address of the host th e RS P software is running on. Th e JIVE_SERVER-PORT sets the port number of th e Jive server. I f this setting is changed

to a non-default value, one will also' have to change the port in j i ve : s t a r t por t in th e/jsegateway file. The default port number is 4711.

Th e INITIAL....NUMBER_OF _SERVERTHREADS is th e number of ServerThreads in th e thread poolat startup.

Th e MAX....NUMBER_OF_SERVERTHREADS is th e maximum number of ServerThreads in th e threadpool.

Before the JSE can be compiled th e JSEROOT, JIVEROOT and JAVAROOT variables in th e/compilejse file have to be edited, so that they reflect the location of the JSE sourcefiles j s e r o o t , th e Jive library j iveclass and the Java compiler javab in . Runningcompilejse will compile the JS E source files.

E.2 The IN Server GUI

When th e IN Server is started with GUl, the display shown in figure E.1 will appear. I t shows a

c: tmbde

found in subscriber 08 . returning OPl

round in subscrtber DB, returning OPl

found In service 08

found in subscrIber 08 , verified location

Figure E.1: The publisher ta b of th e IN Server GUI

tabbed pane with four tabs. Currently, the publisher ta b is active. In the top left corner a list ofcurrently connected JSEs is displayed. In th e top-right corner a list of recently returned objects(DPLs and IN services) is displayed. Below these lists is a log window. In between the two listsare two buttons; one to clear the list with returned objects an d one to clear the log window.

The second ta b is th e service tab. I t is shown in figure E.2. The top-left list shows all knownservices on the IN server. In this case two services, police and j avavpn, are known. The top-right

ERICSSON i!5 89


94/102


Figure E.2: The service tab of th e IN Server QUI

list shows which of these services are currently online. When a service is online it means that a JS Eis able to download it from the server. The add and remove buttons allow services to be added toand removed from th e online-list. vVhen a service is selected in the top-left window, as is currentlythe j avavpn service, the subscribers subscribed to this service are displayed in the bottom list.

The three buttons in the lower-left corner allow manipulation of the all-list. When add servicebutton is pressed a window will pop up prompting for the class name of th e service to be added.The remove service button removes the in the all-list selected services. The replace buttonprompts for th e class name of the to be added service an d replaces th e selected service.

Figure E.3 shows th e subscriber tab. The top-left list shows all known subscribers. In this example

Figure E.3: The subscriber ta b of the IN Server QUI

90 ERICSSON


95/102

Appendix E. User Manual

four subscribers are known. Th e top-right list shows which of these subscribers are allowed toaccess their subscr ibed services. Currently, only subscr iber 007 an d 002 can use their services.Th e two middle buttons allow subscribers to be added to an d removed from th e online-list. Whena subscriber is selected in th e all-list, th e services he is subscribed to are shown in the bottomlist and his present location is displayed. Subscriber 007 is subscribed to both th e police andjavavpn service and is currently home. By default th e DEFAULTLOCATION variable mentioned insection E.1.3 is se t to home. I t it no t possible to add subscribers to th e all-list or for a subscriberto subscribe or unsubscribe to an IN service. Currently, this is hard-coded.

Th e fourth and last ta b is the JSE ta b shown in figure E.4. All known JSEs are shown in the

I addmml

I rem ove I

Figure E.4: The JSE ta b of th e IN Server GUI

top-left list. The ones in th e top-right list are allowed to gain access to th e IN Server. Th e buttonsallow JSEs to be added to and removed from th e online-list. I t is no t possible to add JSEs to theall-list.

E.2.1 The JSE GUI

Th e GUI in figure E.5 will appear when the JSE is started. Th e title bar of th e window showsthe name of th e JSE, in this case etmbede. Th e window itself consists of four areas: "SCFGateway", "SSF", "JobHandler" an d "Cache". In th e SCF Gateway area, a list of currently tothe JSE connected SSFs is displayed. In th e example, Oosterhoutdennett an d Rij endennettare connected to th e JSE. Th e list in th e SSF area remains empty until an SSF is selected in theSCF Gateway area. It then displays th e calls for th e selected SSF that th e JS E is monitoring.In th e example, Rij endennett is selected. Th e JS E monitors two calls; call number 29 forsubscriber 007 and call number 31 for subscriber 010. Th e list in th e JobHandler area shows theeight most recent executed jobs. Th e three types of jobs are displayed in different colors. Th eCache area contains a list of elements that are currently stored in th e cache. DPLs, services anddata elements are displayed in different colors. When one or more of these elements are selectedand the Flush button is pressed, th e elements are removed from the local cache.

ERICSSON a:: 91


96/102


Figure E.5: Th e JSE GUI

E.3 The RSP-software

The directory in which the RSP software is installed will be referred to as .

Some modules of th e RSP software have been changed to make communication with the JSEpossible. Copy th e following files:Copy jsegateway to th e directory.Copy lim_padiO, scf..maniO and scfiO to the /scf directory.Compile th e RSP software by running make in the .

Start the RSP software from the with: e r l -sname etmbede - s in .

E.4 U sing prototype services

Th e RJS package comes with three prototype services:

the Java VP N service, the Police service and

the Test service.

Th e subscriber database contains four subscribers:

James Bond (007) is subscribed to the Java VPN, Police and Test service. Bill Fairbanks (002) is subscribed to the Java VPN service. Alexander Trevelyan (006) is subscribed to the Java VPN service. Austin Powers is subscribed to the Java VPN and Police service.

Th e Java VPN service creates a virtual private network for its subscribers. Every subscriber hasa two digit telephone number and a barring list.

Th e Police service is activated by dialing 112. I t prompts th e subscriber for a personal codenumber. Only if th e number is entered correctly the call is forwarded to a predefined number, inthis case 0169110. Th e personal code number for James Bond an d Austin Powers are respectively007112 and 010112.

Th e Test service prints its version number on the subscriber's telephone display. It was developedto demonstrate how a Java IN service can be updated during runtime. Th e TestServiceiO class

92 ERICSSON ii


97/102


98/102

Acronyms

ADAPIBC PBCSMCAMELCCAFCCFCORBACS-nCSICSPDF P

DP

DPLDSAED P

ETSIFE

FEAGF P

GMSCGSMHLRHTMLID L

IF

nopININCMIP

ITUJC A

JC E

JD K

JR E

JS E

JVMMSCO-CSIOMGORB

AdjunctApplication Programming Interface

Basic Call ProcessBasic Call State ModelCustomized Application for Mobile network Enhanced LogicCall Control Agent FunctionCall Control FunctionCommon Object Request Broker ArchitectureCapability Set nCAMEL Subscription InformationCryptographic Service ProviderDistributed Functional PlaneDetection Point

Detection Point ListDigital Signature AlgorithmEvent Detection PointEuropean Telecommunication Standards InstituteFunctional EntityFunctional Entity ActionGlobal Functional PlaneGateway Mobile services Switching CenterGlobal System for Mobile communicationsHome Location RegisterHypertext Markup Language

Interface Definition LanguageInformation FlowInternet Inter-ORB ProtocolIntelligent NetworkIntelligent Network Conceptual ModelIntelligent PeripheralInternational Telecommunication UnionJava Cryptography ArchitectureJava Cryptography ExtensionJava Development KitJava Runtime EnvironmentJava Service Environment nodeJava Vir tual MachineMobile services Switching CenterOriginating CAMEL Subscription InformationObject Management GroupObject Request Broker

ERICSSON 95


99/102


96

OSSPC CPCNPE

PI CPI D

PO I

PO RRJSRMIRSPSCEFSCEPSCFSCP

SDFSDPSESFSIBSMAFSMAPSMFSMPSNSRF

SSCPSSFSSPT-CSITD PUMLUR L

VLRVPN

Operator-Specific ServicesProof-Carrying CodePersonal Communication NetworkPhysical Entity

Point in CallProcess IdentificationPoint of InitiationPoint of ReturnRoaming Java IN Service(s)Remote Method InvocationRapid Service PrototypingService Creation Environment FunctionService Creation Environment PointService Control FunctionService Control Point

Service Data FunctionService Data PointService EnvironmentService FeatureService Independent Building BlockService Management Access FunctionService Management Access PointService Management FunctionService Management PointService NodeSpecialized Resource Function

Service Switching and Control PointService Switching FunctionService Switching PointTerminating CAMEL subscription InformationTrigger Detection PointUnified Modeling LanguageUniform Resource LocatorVisitor Location RegisterVirtual Private Network

ERICSSON


100/102

Bibliography

[1] J. Armstrong, R. Virding and M. Williams, "Concurrent Programming inERLANG ", ISBN 0-13-285792-8, Prentice Hall International, 1993, available athttp://wv/w.erlang.se/erlang/sure/main/news/erlang-book-part1.pdf

[2] Special Mobile Group (SMG) of the ETSI, "Digital cellular telecommunications system(Phase 2+); Customized Applications for Mobile network Enhanced Logic (CAMEL) - Stage2 (GSM 03.78 version 5.1.0)", version 5.1.0, August 1997, inside Ericsson available at:http://www.gsm.ericsson.se/standard/gsmph2+/camel/0378-51O.pdf

[3] Special Mobile Group (SMG) Technical Committee (TC) of th e ETSI, "Digital cellulartelecommunications system (Phase 2+); Customised Application for Mobile network Enhanced Logic (CAMEL) - Phase 2; Stage 2 (GSM 03.78)", October 1997, inside Ericssonavailable at: http://\\rww.gsm.ericsson.se/standard/gsmph2+/camel/378a08r5.pdf

[4] K. Campbell, "Custom Class Loaders Using Java", Developer's Journal, Interface Technolo

gies, Inc, 1998, available at ftp://ftp.iftech.com/DevJournal/ccl/ccl.pdf[5] D.M. Chess, C.G. Harison an d A. Kershenbaum, "Mobile agents: Are they a good

idea?", IBM Research Report, T. J. \Vatson Research Center, October 1994, available athttp://www.researchoibm.com/massive/mobag.ps

[6] D. Chess, B. Grosof, C. Harrison, D. Levine and C. Parris, "Itinerant Agents for MobileComputing", IBM Research Report, T. J. Watson Research Center, March 1995, available athttp://www.research.ibm.com/massive/rc20010.ps

[7] B. Eckel, "Thinking in Java", ISBN 0-13-659723-8, Prentice-Hall Inc., 1998, available atftp://www.mindview.net/pub/eckel/printabl.pdf

[8J , No author given, "Virtual Private Network VPN 2.2.1, Service Overview, Structure andFeature Description", EN/LZT1120012.R2B, Ericsson Telecom AB, September 1997, insideEricsson available at: http://sad.etm.ericsson.se/products/documents/vpn221R4so.pdf

[9] , No author given, "Network Overview and Traffic Cases Description for VPN 2.2.1",No.: 1/190 59-FAM 511 02 UEN, Ericsson, May 1998, inside Ericsson available at:http://sad.etm.ericsson.se/products/documents/vpn221R4no.pdf

[10] ,N o author given, "The FSP Pototype, The SSF Part", ETM/C/XU 93:046, Ericsson, November 1993

[11] J. Feigenbaum and P. Lee, "Trust Management and Proof-Carrying Code in Secure MobileCode Applications", DARPA workshop on Foundations for Secure Mobile Code, March 1997,available at http://www.cs.nps.navy.mil/research/languages/statements/leefeLps

[12] L. Gong, M. Mueller, H. Prafullchandra and R. Schemers, "Going Beyond th e Sandbox: AnOverview of th e New Security Architecture in the Java Development Ki t 1.2", In Proceedings of the USENIX Symp. on Internet Technologies and Systems, Monterey, California,December 1997, available at http://java.sun.com/people/gong/papersfjdk12arch.ps.gz

ERICSSON 97


101/102


[13J L. Gong an d R. Schemers, "Implementing Protection Domains in theJava Developement Kit 1.2", In Proceedings of the Internet Society Symp. onNetwork and Distributed System Security, San Diego, CA, March 1988, available athttp://java.sun.com/people/gong/papers/jdkI2impl.ps.gz

[14J J. Gosling, B. Joy and G. Steele, "The Java Language Specification", ISBN 0-201-63451-1,Addison Wesley, 1996, available at ftp://ftp.javasoft.com/docs/specs/langspec-l.O.pdf

[15J R.S. Gray, D. Kotz, G. Cybenko and D. Rus, "D' Agents: Security in aMultiple-language mobile-agent system", Dartmouth College, 1998, available athttp:// actcomm.dartmouth.edu/papers gray:security- book ps.Z

[16J C.G. Harrison, "Smart Networks and Intelligent Agents", IBM T. J. Watson Research Center,available at http://www.research.ibm.com/massive/smartnw.ps

[17J F. Hohl, "An Approach to Solve th e Problem of Malicious Hosts in Mo-bile Agent Systems", University of Stuttgart, IPVR, 1997, available athttp://www.informatikuni-stuttgart.de/ipvr/vs/mitarbeiter/hohlfz/sosp97.ps

[18J Douglas Kramer, "The Java Platform, A white paper", May 1996, available athttp://java.sun.com/docs/white/platform/CreditsPage.doc.html

[19] Laura Lemay an d Rogers Cadenhead, "Teach Yourself Java 1.2 in 21 days", ISBN 1-57521-390-7, Sams Publishing, May 1998, refer to http://prefect.com/java21/

[20) No author given, "Fundamentals of Java Security", MageLang Insitute , 1998, available athttp://developer.java.sun.com/developer onlineTraining/Security abstract.html

[21; C. McManis, "The basics of Java class loaders", Java World, October 1996, available at

http://www.javaworld.com/javaworldfjw-lO-I996/jw-10-indepth.html[22] C. Meadows, "Detecting Attacks on Mobile Agents", DARPA work-

shop on Foundations for Secure Mobile Code, March 1995, available athttp://www.cs.nps.navy.mil/research/languages/statements/meadows.ps

[23] J.T. Moore, "Mobile Code Security Techniques",an d Information Science, University of Pennsylvania,http://www.cis.upenn.edu/jonm/papers/cis700.ps

DepartmentMay 1998,

of Computeravailable at

[24] K. Nygren, J. Grebeno, "Jive Application (JIVE)", part of the Open Source Erlang documentation, may 1997, available at http://w\vw.erlang.org/doc/doc/libfjive-1.2/doc/bookps.gz

[25] J.J. Ordille, "When agents roam, who can you trust?", Computing Science Research Center,Bell labs, 1996, available at http://cm.bell-Iabs.com/cm/cs/doc/96/5-09.ps.gz

[26] T. Sander and C.F. Tschudin, "Protecting Mobile Agents Against Malicious Hosts", in Lecture Notes in Computer Science (LNCS), Vo1.l419, Springer-Verlag, June 1998, available athttp://www.icsi.berkeley.edu/sander/publications/MA-protect.ps

[27] T. Sander and C.F. Tschudin, "Towards Mobile Cryptography",of th e 1998 IEEE Symp. on Security an d Privacy, May 1998http://www.icsi.berkeley.edu/sander/publications/satschu.ps

Proceedingsavailable at

[28] No author given, "Clarifications and Amendments to The Java Language Speci

fication, Technical Rationale on Class Unloading", Sun Microsysterns, available athttp:/ fjava.sun.com/docs/books/jls/unloading-rationale.html

[29] No author given, "Java Remote MethodComputing for Java", white paper, Sunhttp://java.sun.com/ marketing/ collateral/javarmLhtml

98 ERICSSON

InvocationMicrosystems,

Distributedavailable at


102/102

BIBLIOGRAPHY

[30] No author given, ''Java Remote MethodVlSlOn 1.50, JD K 1.2, Sun Microsystems,ftp:/ /ftp.javasoft.com/docs/jdk1.2/rmi-spec-JDK1.2.pdf

InvocationOctober

Specification" ,1998, available

Reat

[31] No author given, ''Java RMI Security Extension, Early Look Draft", Sun Microsystems,May 1999, available at http://www.javasoft.com/productsfjdk/rmi/rmi-security.pdf

[32] No author given, "The Java Language: An overview", Su n Microsystems, 1994, availableat ftp://ftp.javasoft.com/docs/papers/java-overview.ps

[33] Telecommunication Standardization Sector of ITU, Recommendation Q.120x, inside Ericssonavailable at:http://mirad.etm.ericsson.se/COMPAREA/STANDARD STANDARD /ITU /INAP /

[34] Telecommunication Standardization Sector of ITU, Recommendation Q.121x, inside Ericssonavailable at:

http://mirad.etm.ericsson.se/COMPAREA/STANDARD STANDARD /ITU INAP /

[35J Ja n Thorner, "Intelligent Networks", ISBN 0-89006-706-6, Artech House, 1994

[36] No author given, "UML Notation Guide", version 1.1, Rational Software Corporation,September 1997, available at http://www.rational.com/uml

[37] Giovanni Vigna (Ed.), "Mobile Agents and Security", ISBN 3-540-64792-9, Lecture Notes inComputer Science, Springer, 1998

[38J Giovanni Vigna, "Mobile Code Technologies,tions" , PhD Thesis, Politecnico di Milano,

http://www.cs.ucsb.edu/vigna/pub/phdthesis.ps.gz

Paradigms,February 1998,

an d Applica-available at

[39J B. Yee, "A Sanctuary for Mobile Agents" , March 1995, available athttp://www.cs.nps.navy.mil/research/languages/statements/bsy.ps

Documents

Roaming Java Services