A Common Framework for Integrating Wireless, Wireline and Internet Networks

Transcription

1 A Cmmn Framewrk fr Integrating Wireless, Wireline and Internet Netwrks Maurizi Bnuccelli (1), Pier Lauri (2), Francesca Martelli (3) $EVWUDFW In this reprt, the setting f the new prject n integrating wireless, wireline and internet netwrks in JAIN initiative fr MAP is presented. First, the JAIN initiative is intrduced, alng with its main features and requirements. Then, a general verview f GSM systems wrking is presented. After intrducing the main architectural cmpnents f GSM systems, MAP prtcl is described. Later, the presentatin fcuses n the main prject subject, namely JAIN MAP API, its capabilities and the cmmunicatin structure. Finally, the current status f the prject, namely the implementatin f shrt message service (SMS fr shrt) part f JAIN MAP, and the future develpments (extending such SMS service t include a multicasting feature) cnclude the reprt..h\:rugvfrppxqlfdwlrqsurwrfrov-$,10$3*60v\vwhpvvkruwphvvdjhvhuylfh (1) Dipartiment di Infrmatica, Università degli Studi di Pisa. (2) Ericssn Lab Italy, Rma. (3) Istitut dell Elabrazine dell Infrmazine, CNR Pisa. 1

2 1 Intrductin Telecmmunicatins systems have gained a paramunt imprtance in everyday mdern life, pervading each aspect f it; wrk, leisure, family life. Three different systems emerged as the main carriers f cmmunicatin bject: traditinal wired (i.e. telephne) netwrks, internet and the mst recent wireless (bth infrastructured and ad hc) netwrks. At the same time, a cmmn cmmunicatin paradigm is impsing its advantages ver the thers: the digital ne. Given this scenari, the integratin f the abve three systems is a must. The advantages brught by such an integratin are dubtless and manifld. Several prpsals fr such an integratin, perating at different levels f the systems prtcl hierarchy, have been dne. One f these is the JAIN MAP initiative, centred arund wireless netwrks, which is the subject f ur prject. In this reprt, we shall first describe the JAIN initiative. Then, we shrtly intrduce GSM systems and MAP prtcl. Later, JAIN MAP API main features are presented. The reprt ends with an utline f the wrk that we plan t carry ver in the near future. 2 JAIN 2.1 Objective The bjective f the JAIN (Java API s fr Integrated Netwrk) initiative is t bring service prtability and netwrk cnvergence int the telephny netwrk [9]. The JAIN initiative wants t integrate wireline (PSTN, Public Switched Telephne Netwrk), wireless (PLMN, Public Land Mbile Netwrk) and packet based (IP, Internet Prtcl and ATM, Asynchrnus Transfer Mde) netwrks by prviding a new level f abstractin. JAIN encmpasses a standard set f interfaces fr service creatin and a number f standard interfaces fr service executin. JAIN technlgy enables the integratin f Internet and Intelligent Netwrk. Furthermre, the initiative wants t allw Java applicatins t have secure access t resurces inside the integrated netwrk. The JAIN initiative cnsists f tw areas f develpment: The Prtcl API Specificatins, which specify interfaces t wireline, wireless and IP 2 signalling prtcls;

3 The Applicatin API Specificatins, addressing the API s required fr service creatin within a Java framewrk spanning acrss all prtcls cvered by the Prtcl API Specificatins. 2.2 Business Drivers and Gals The purpse f JAIN initiative is t build a sftware platfrm cmpliant with the fllwing requirements: Service prtability: the Java slgan is Write Once, Run Anywhere. Technlgy develpment is currently cnstrained by prprietary interfaces: this increases develpment csts, time t market and maintenance requirements. With the JAIN initiative, prprietary interfaces are reshaped t unifrm Java interfaces delivering truly prtable applicatins. Netwrk cnvergence: t make a single integrated netwrk. By delivering the facility t allw applicatins and services t run n PSTN, packet and wireless netwrks. Secure netwrk access: by enabling applicatins residing utside the netwrk t directly access netwrk resurces creating a new envirnment fr develpers and users. Develping these three requirements, n mre prprietary interfaces, secure access int a single public netwrk, the JAIN initiative wants t transfrm the telecmmunicatin market frm many prprietary clsed systems t a single pen envirnment able t hst a large variety f services. Besides, JAIN technlgy makes telecm applicatin develpment faster, simpler and less expensive. In the fllwing figure, the main parts f the JAIN prgram are utlined. JAIN prgram Prtcl Expert Grup Applicatin Expert Grup SIP Edit grup JSC/SLEE MAP Edit grup JAIN Parlay MGCP Edit grup JCC/JCAT H.323 Edit grup Cnnectivity Management AIN/INAP Edit grup TCAP Edit grup ISUP Edit grup OAM & Prvisinig Edit Grup Figure 2.1 The JAIN Cmmunity In this prject, we will fcus ur wrk in JAIN MAP API, part f the Prtcl Expert Grup. The bjective is t prvide an pen and extensive API n a level f abstractin that hides the 3

4 hetergeneity f the different underlying MAP prtcls (ETSI MAP and ANSI MAP, each with different versins). 3 GSM System The mst used mbile systems are the cellular nes, in which a set f Base Statins (BS) crdinate the infrmatin exchange (manage the cmmunicatins) f several Mbile Statins (MS) each raming in the area supervised by a BS, and called cell. Base Statins are prperly cnnected, usually via the fixed cmmunicatin infrastructure, t allw the cmmunicatin between remte mbile terminals. We can cnsider the GSM system as a three layers architecture [1,2]: 1. The radi system; 2. The switches; 3. The databases. The switches tgether with the databases frm the s-called Netwrk and Switching Subsystem (NSS): which is the subsystem studied in ur prject. The relevant subscriber data (e.g. its lcatin) are stred in a vital database f the GSM netwrk, called HLR (Hme Lcatin Register). A set f cells is managed by a single MSC (Mbile Switching Centre) tgether with a database called VLR (Visitr Lcatin Register), a kind f HLR cache. Entities cmmunicate with each ther thrugh prper interfaces, which can be internal r external: internal when tw functinal entities are physically c-lcated in ne equipment, external therwise (in which case standardized signalling prtcls shall be used). In the latter case, the current standard is the SS7 (Signaling System N. 7) prtcl stack, shwn in the figure, Call-related signaling N call-related signaling MAP ISUP TCAP SCCP MTP3 MTP2 MTP1 Figure 3.1 The Signaling System 7 Stack 4

5 where: MTP (Message Transfer Part): these are three layers crrespnding t the OSI physical layer, data link layer and netwrk layer, respectively; SCCP (Signaling Cnnectin Cntrl Part): gives bth cnnectinless and cnnectin riented netwrk services and prvides additinal functins such as Glbal Title Translatin; TCAP (Transactin Capabilities Applicatin Part): prvides the capability t exchange infrmatin between applicatins using nn-circuit related signalling; ISUP (ISDN User Part): used t set-up and release calls; MAP (Mbile Applicatin Part): used fr signaling related t a number f services. 3.1 MAP Prtcl The prtcl subject f this prject is MAP. It shuld be cnsidered as a number f prtcls, rather than a single prtcl, because different parts f MAP are used n several different interfaces between a number f functinal entities in the mbile telephne netwrk [5,6,7]. The services carried ut by MAP are: Cmmn MAP services: pen and clse MAP dialgue, data delimiter, user and prvider abrt, prvider ntice; Mbility services: lcatin management, paging, access management, handver, authenticatin management, security management, IMEI management, subscriber management, identity management, fault recvery, subscriber infrmatin; Operatin and maintenance services: fr example subscriber tracing; Call handling services: prvisin f ruting infrmatin, grup call management, status reprting; Supplementary services and related services: registratin, erasing, activatin, deactivatin, interrgatin, invcatin f supplementary services, passwrd management, USSD (Unstructured Supplementary Service Data); Shrt message service management services: prvisin f ruting infrmatin, frwarding f mbile riginated and mbile terminated shrt message, delivery status reprting, alert service centre, miscellaneus infrmatin services; 5

6 GPRS services: request GPRS ruting infrmatin, failure reprt, and mbile statin present fr GPRS. The GSM entities cmmunicate each ther t carry ut sme service, thrugh MAP dialgues, by invking MAP service primitives. Service primitives can be f fur types: Request, Indicatin, Respnse and Cnfirm. A MAP service user f a netwrk entity (called the dialgue initiatr) initiates the service primitive and the service type is Request, as shwn in the next figure. DIALOGUE INITIATOR MAP Service User DIALOGUE RESPONDER MAP Service User REQUEST CONFIRM RESPONSE INDICATION MAP Service Prvider MAP Service Prvider Figure 3.2 GSM MAP service mdel This service request is sent t the MAP service prvider f the netwrk entity, fr delivering it t the peer netwrk entity (the dialgue respnder) by using a lwer-layer prtcl (TCAP). When the MAP service prvider f the peer netwrk entity receives the request, it invkes the same service primitive with type Indicatin t infrm the destinatin MAP service user. The primitive is typically a query, which asks the dialgue respnder t perfrm sme peratins. A crrespnding service acknwledgment, with r withut results, may be sent frm the dialgue respnder t the dialgue initiatr invking the same service primitive with type Respnse. After that, the MAP service prvider f the dialgue initiatr receives the respnse and invkes the same service primitive, but with type Cnfirm. Nte that the parameters f the Request and Indicatin services, and Respnse and Cnfirm services, are identical in mst cases, except when errrs happened. 3.2 MAP Capabilities The first MAP capability addressed in ur prject will be the Shrt Message Service capability [8]. This service des nt require the end-t-end establishment f a traffic path: it is asymmetric, i.e. Mbile Originating Shrt Message transmissin is cnsidered as a different service frm Mbile Terminating Shrt Message transmissin. Besides, the ultimate destinatin, identified by sme field 6

7 in the message, is relevant nly fr the user and the SMSC (Shrt Message Service Centre, see figure), nt fr the GSM infrastructure. The MAP services fr Shrt Message Service are: Prvisin f ruting infrmatin; Frwarding f Mbile Originating (frm MS t SMSC) and Mbile Terminating (frm SMSC t MS) SMS messages; Delivery status reprting; Alert service centre, when the final MS is nt available t receive the Shrt Message. In particular, the entities invlved in this service are depicted in the next figure: VLR MSC SMSgwy HLR SMSC IWMSC Figure 3.3 Entities f NSS invlved in SMS service In SMS service, the main task are develped by Shrt Message Service Centres (SMSC): as we said, a mbile statin send the shrt message tward a service centre and after that the service centre try t send the shrt message t the destinatin mbile statin. Smetimes, this last transmissin is nt pssible because the destinatin is nt reachable r its memry is full: in such cases, the service centre attend an alert message by the Hme Lcatin Register (HLR), indicating that the mbile statin is available t receive shrt messages and then it sends the message. The SMS-gateways (SMSgwy) and InterWrking MSC s (IWMSC) are entities whse interfaces are used by the SMSC fr utging and incming cmmunicatin, respectively. The Mbile Switching Centres (MSC) send and receive the shrt message by and t a mbile statin with the cllabratin f the Visitr Lcatin Registers (VLR); the Hme Lcatin Register prvides infrmatin abut ruting, i.e. tward what MSC the message must be ruted. The MAP primitives, listed belw, and exchanged between the entities, are gruped n a service base. 7

8 FORWARD MOBILE ORIGINATING SHORT MESSAGE: MAP_SEND_INFO_FOR_MO_SMS between MSC and VLR MAP_MO_FORWARD_SHORT_MESSAGE between MSC and IWMSC FORWARD MOBILE TERMINATING SHORT MESSAGE: MAP_SEND_ROUTING_INFO_FOR_SM between SMSgwy and HLR MAP_MT_FORWARD_SHORT_MESSAGE between SMSgwy and MSC MAP_SEND_INFO_FOR_MT_SMS between MSC and VLR SHORT MESSAGE ALERT SERVICE CENTRE: MAP_READY_FOR_SM between VLR and HLR MAP_ALERT_SERVICE_CENTRE between HLR and IWMSC SHORT MESSAGE DELIVERY STATUS REPORT: (MAP_MT_FORWARD_SHORT_MESSAGE_ACK/NACK frm MSC t HLR) MAP_REPORT_SM_DELIVERY_STATUS between SMSgwy and HLR There are ther service primitives, but we mit them fr the sake f brevity. In the next figure, we shw an example f service primitives invked fr delivering a shrt message. ( ' MS1 Submit SM MS2 MSC1+ $FN MS2 switched n Ack Ack VLR1 Frward MO SM Deliver SM MSC2 + VLR2 SMSC & Ack Send ruting inf Ruting inf Frward MT SM Nack (MS2 switched ff) Reprt SM waiting Ack Reprt ready fr SM Ack Frward MT SM Ack Ack Alert SMSC HLR Figure 3.4 Example: shrt message sent frm a MS t anther MS 8

9 Nte that we mitted the cmmn MAP services: in practice, each service invked is preceded by an pening f the MAP dialgue and fllwed by a delimiter peratin r clsure f the MAP dialgue. Besides, the functinal entities SMSgwy, IWMSC and SMSC are integrated in ne entity, called SMSC, and the VLR entity is integrated in MSC, als. 4 JAIN MAP API In the first release f JAIN MAP API, nt all the functinalities f the prtcl will be implemented, but nly a subset shall be chsen, the subset that is cnsidered t be the mst interesting ne fr applicatin develpers: Sending/receiving shrt messages; Retrieval f infrmatin abut mbile telephnes; Exchange f service specific data between the mbile telephne and a service applicatin in the PLMN. We have t cnsider is the different standards that will be included in this versin, als. First, the ETSI MAP and the ANSI MAP (IS41/ANSI41) with all their different versins will be studied. Anther aspect t investigate in JAIN MAP scping space is the level f abstractin. Obviusly, frm an applicatin develpers pint f view a high level f abstractin is desirable: as few primitives as pssible, as few parameters as pssible in each primitive and as much details f the underlying prtcl as pssible, hidden. When cnsidering a lw level f abstractin, it will prbably be necessary t specify separate interfaces fr each prtcl that the API is ging t supprt. Figure 4.1 Scping space fr JAIN MAP API 9

10 It has been decided that the first versin shall be n a relatively high level f abstractin [3]. This, f curse, will determine a mre cmplex implementatin f the JAIN MAP API fr the vendr. In figure 4.1 we shw that there are three directins f develpment: number f capabilities (and entities invlved in each capability), prtcl and level f abstractin. The scpe fr the first versin f the JAIN MAP API is represented by the black circle in the figure. The capabilities shwn in the figure, typically invlve cmmunicatin between several functinal entities in the mbile netwrk. The prtcl prcedures f the MAP prtcl fr a certain capability are different in different types f functinal entities. This means that the API fr a certain capability will be different fr different functinal entities. 4.1 JAIN MAP Capabilities The first release f the JAIN MAP API specificatin supprts fur capabilities [3], listed belw: Message Transactin Capability: the Shrt Message Service, available in bth ETSI MAP and ANSI MAP. This capability can be implemented n different levels: when implemented n a high level, the JAIN MAP API User applicatin handles the messages as simple text strings, whereas JAIN MAP API implementatin must handle the frmatting f the shrt message, accrding t the standard; therwise, this is a task f the applicatin. We chse t implement the present capability n a high level, in rder the meet the main bjective f JAIN. Message Sessin Capability: enable a service applicatin t exchange data with a mbile statin. It is based n the Unstructured Supplementary Service Data (USSD) capability f the ETSI MAP prtcl. MS Infrmatin Capability: based n the Any Time Interrgatin (ATI) capability f the ETSI MAP prtcl. It permits the interrgatin f mbile statin lcatin and status. MS Psitin Capability: based n the Lcatin Service (LCS) capability f the ETSI MAP prtcl and Emergency Lcatin specified in ANSI. The main purpse f JAIN initiative is t abstract the different functinalities f the MAP prtcls as much as pssible t btain a simple API t be used by the JAIN MAP API User applicatins. The set f functinalities supprted by the JAIN MAP API is nt limited t the least cmmn subset f functinalities f the MAP prtcls, but includes functinalities supprted by any f the MAP prtcls that are useful fr the JAIN MAP API User applicatin. This implies that nt all 10

11 capabilities in the abstract JAIN MAP API can be mapped t all prtcls, but it is respnsibility f each MAP stack vendr implementing the JAIN MAP API t map the API functinality t the specific MAP prtcl in the best pssible way [3]. Fr example, if an applicatin tries t use primitives that are nt supprted, an exceptin will be returned. Besides, primitive parameters representing functinalities that are nt present in all prtcls supprting a capability are made ptinal in the JAIN MAP API specificatin. The JAIN MAP API must prvide methds t check which ptinal parameters will be in a specific instance f a primitive: parameters that are nt supprted shall be ignred by the JAIN MAP API implementatin. Since the prtcl behaviur fr a certain capability is (usually) different in different functinal entities in the mbile netwrk, the capabilities in the JAIN MAP API are defined per functinal entity. The first release f JAIN MAP API Specificatin supprts the fllwing capabilities and functinal entities: Message Transactin Capability: fr this capability, the JAIN MAP API prvides functinality f the Shrt Message Service Centre and the SMS-gateways in the ETSI MAP reference mdel and the Message Centre in the ANSI reference mdel. Message Sessin Capability: fr this capability, the JAIN MAP API prvides functinality f the gsmscf (GSM Service Cntrl Functin, managing applicatins fr Intelligent Netwrk) in the ETSI MAP reference mdel. MS Infrmatin Capability: fr this capability, the JAIN MAP API prvides functinality f the gsmscf in the ETSI MAP reference mdel. MS Psitin Capability: fr this capability, the JAIN MAP API prvides functinality f the GMLC (Gateway Mbile Lcatin Centre) in the ETSI MAP reference mdel and f the ESME (Emergency Services Message Entity) and MPC (Mbile Psitin Centre) in the ANSI reference mdel. Fr each capability, there are ne r mre peratins, and primitives are defined fr each peratin. Primitives are f fur distinct types: Request, Indicatin, Respnse and Cnfirmatin, with the same meaning as MAP primitives (see sectin 3.1). Fr Message Transactin Capability three peratins are expected: MtMessage: Sending a message t Mbile Statin. The underlying prtcl is SMS (in ETSI r ANSI MAP). 11

12 MMessage: Receiving message frm MS. The underlying prtcl is SMS (in ETSI r ANSI MAP). MtMessageRecAvail: A ntificatin frm the netwrk that the receiver f a message is nw active and prepared t receive. This feature is available ANSI SMS and ETSI SMS. Fr Message Sessin Capability, three peratins are expected: SessinOpen: Opening a sessin. Open messages cntain user data. Initiated frm netwrk side (Req) r by MS (Ind). The underlying prtcl is ETSI USSD. SessinData: Data messages exchanged after SessinOpen. SessinClse: Clsing a sessin. Always initiated by the netwrk side. Clse messages cntain user data nly if the sessin was initiated by the MS. Fr MS Infrmatin Capability, nly ne peratin is expected: MsInf: Get MS lcatin (zne) and MS status. Fr MS Psitin Capability, tw peratins are expected: MsPs: The psitin (crdinates) f an MS is retrieved frm the netwrk. The underlying prtcl may be LCS (Lcatin Service) in ETSI MAP r ANSI Emergency Lcatin prtcl PN The psitin (crdinates) f an MS is queried frm e.g. an LCS client. MsPsReprt: In emergency calls the psitin (crdinates) f an MS is pushed by the netwrk, in particular the requiring entity is the serving MSC fr the area in which the MS is lcated. The primitives specified fr the JAIN MAP API are mapped t primitives f the MAP layer by JAIN MAP API Implementatin. It is imprtant t realize that there is nt a ne t ne mapping f JAIN primitives and MAP primitives. The JAIN MAP API implementatin acts as an abstractin layer that cnsistently reduces the cmplexity f the MAP layer interactin. 12

13 4.2 JAIN MAP API Cmmunicatin The JAIN MAP API enables exchange f data between JAIN MAP API User applicatins and MAP prtcl stack, as shwn in figure 4.2. The tpmst layer f a MAP prtcl stack is the MAP layer that prvides services t the JAIN MAP User applicatin thrugh the JAIN MAP API. JAIN MAP API User Applicatin JAIN MAP API Primitives MAP Stack Figure 4.2 JAIN MAP API Overview The infrmatin exchange is mdelled as primitives that can be thught f as abstract prcedure calls carrying a number f parameters. Tw different MAP stacks exist, ne specified by ETSI (eurpean) and ne by ANSI (american): these tw prtcls prvide different cmmunicatin mechanisms fr a great number f different capabilities. The primitives specified fr the JAIN MAP API are mapped int primitives f the MAP layer by the JAIN MAP API implementatin. It is imprtant t see that there is nt a ne t ne mapping between JAIN MAP API primitives and MAP primitives. The JAIN MAP API implementatin acts as an abstractin layer that reduces the cmplexity f the MAP layer, and s simplifies the interactin between MAP and user applicatins. The JAIN MAP API specificatin has the fllwing main parts: One Listener interface class fr each capability: the JAIN MAP API User applicatin must implement the Listener interfaces fr the capabilities that the applicatin shall use. One Prvider interface class fr each capability: the JAIN MAP API implementatin must implement the Prvider interfaces fr all the capabilities that shall be supprted by the JAIN MAP API implementatin. One class fr each primitive: the primitive classes are Java Events because the JAIN MAP API is based n the Java Event mdel and the primitives are treated as events. This is necessary in rder t btain an asynchrnus behaviur f the JAIN MAP API. 13

14 One class fr each cmplex parameter: nly parameters that are nt basic builtin types f the Java language are classes. One class fr each exceptin: fr each exceptin that can happen, a class must be prvided. A Stack interface: the JAIN MAP API implementatin must cntain ne r mre classes that implement the Stack interface. A stack bject represents a particular stack; there shall be ne instance f a stack bject fr each stack in the system that may be used via the JAIN MAP API. A Factry class: the Factry class is used t instantiate the stack bject(s). JAIN MAP API User Applicatin JAIN MAP API Listener JAIN MAP API Events JAIN MAP API JAIN MAP API Prvider MAP Layer TCAP Layer Figure 4.3 JAIN MAP API Mdel Figure 4.3 illustrates hw passing f primitives in the JAIN MAP API takes place between the listener bjects and prvider bjects. An applicatin that wants t asynchrnusly receive primitives initiated by anther party must register a listener with the suitable prvider bject. Such primitives are received as events accrding t the Java event mdel. Primitives sent by the applicatin are sent by a direct methd invcatin n a suitable prvider bject. When the applicatin sends a request primitive fr which it expects a cnfirmatin, a listener reference ("callback") is given t the prvider, which will be used t deliver the cnfirmatin asynchrnusly. 14

15 5 Current state f the prject As described in the previus sectin, fr each capability a listener and a prvider bjects must be given. The listener bject will be given by the applicatin and it will cmmunicate with the prvider bject that will be given by the stack vendr accrding t the JAIN MAP Requirements [3]. A simple test applicatin with a listener bject has been created t verify ur JAIN MAP API implementatin. A textual interface has been designed t send JAIN MAP primitives. We are currently wrking tward prducing a generic prvider bject which respect the requirements fr each capability, handling several listener bjects and transactins. Presently, nt all the requirements are met: in fact the actual implementatin is limited t the case where listener and prvided bjects are created in the same Java virtual machine. JAIN MAP API Listener JAIN MAP API Prvider Prvider instance created TransId=prvider.prcess<capability>Operatin(eventRef,listener) Listener.prcess<capability>Event(eventRef,transId) Outging peratin Prvider.add<capability>Listener(listener,address) listener.prcess<capability>event(eventref,transid) Prvider.prcess<capability>Operatin(eventRef,transId) Incming peratin Figura 5.1 Principle fr Listener registratin and Event passing The first step t develp the JAIN MAP API primitives was studying the MAP prtcl in the ETSI MAP reference mdel. The initial prblem was the mapping between the JAIN MAP primitives and the ETSI MAP primitives. In particular we started ur design with the Message Transactin Capability and then the shrt message handling in a PLMN netwrk. Fr this reasn, we needed understanding the behaviur f the SMS-gateway and IWMSC functinal entities in a PLMN netwrk (see sectin 3.2). The first JAIN MAP primitive implemented has been the MtMessage. Such primitive is mapped int a number f MAP dialgues between different functinal entities: SMS-gateway, IWMSC, HLR, MSC mbile terminated (see the ETSI MAP standard). 15

16 The remaining primitives were studied t, and a skeletn was prvided fr each ne f them. T start with wrked n a symblic representatin f primitive parameters. The implementatin with actual parameters will fllw shrtly. The prper testing f ur prject must be carried ut by using a MAP stack r at least a MAP simulatr. Obviusly, this aspect falls beynd the prject purpse. We are still lking fr a prper slutin t this prblem. 6 Future Develpments After implementing the JAIN MAP API part fr SMS capability, the wrk will be pursued in tw directins. On ne hand, we ll cntinue implementing ther capabilities, in rder t cmplete the whle implementatin. On the ther hand, we shall start investigating the implementatin f new features fr SMS capability. The new feature we shall start with is message multicasting. In this feature, the same message must be sent t a set f mbile terminals, and nt t nly ne, like in usual SMS service. Such a feature is interesting in several applicatin, specially in a cmpany ne. Imagine that the manager f a grup wants t send the same message t all the peple wrking n a particular prject. With the current SMS service, she/he has t write the message and send it separately t each receiver, pssibly by writing each number separately. Besides, n the system side, each cpy will travel as a different and separate message, withut taking advantage f the cmmn parts f the rutes tward the final destinatins. Fr instance, imagine that all the persns that just receive the message are in the same cell. Withut multicasting, each cpy f the message travels in the netwrk as a separate message, while with multicasting nly ne cpy f it will g frm the sender t the final base statin, thus saving a cnsiderable amunt f bandwidth. There are several ways f perfrming a multicast send, each with its wn advantages and disadvantages. In this part f the prject, we first shall investigate n the ways t perfrm multicasting taking int accunt perfrmance, simplicity and easy f implementatin. Later, nce the prperties f the chsen slutin have been btained, the actual implementatin will take place, and figures n the advantages ver the nn-multicasting alternative will be gathered. 16

17 %LEOLRJUDSK\ [1] Yi-Bing Lin, Imrich Chlamtac Wireless and Mbile Netwrk Architectures. Wiley Cmputer Publishing, [2] Michel Muly, Marie-Bernadette Pautet The GSM System fr Mbile Cmmunicatins. Muly, [3] JAIN MAP Edit Grup Java[tm] API s fr the Integrated Netwrk, JAIN[tm], Framewrk Requirement Specificatin fr Mbile Applicatin Part (MAP). Internal draft. [4] Sun Micrsystems Open Prcess fr Develping and Revising Java Specificatins (Versin 1.0, December 1998), Java Sftware, Sun Micrsystems, Inc. ( [5] ETS V Digital cellular telecmmunicatins system (Phase 2+); Mbile Applicatin Part (MAP) specificatin (GSM 09.02). [6] TS V Digital cellular telecmmunicatins system (Phase 2+); Mbile Applicatin Part (MAP) specificatin (GSM versin Release 1997). [7] TS V Digital cellular telecmmunicatins system (Phase 2+); Mbile Applicatin Part (MAP) specificatin (GSM versin Release 1998). [8] GSM V Digital cellular telecmmunicatins system (Phase 2+); Technical realizatin f the Shrt Message Service (SMS); Pint-t-Pint (PP) (GSM versin Release 1998). [9] JAIN[tm]: Integrated Netwrk APIs fr the Java[tm] Platfrm, White paper. 17