Platform for Control and Delivery of services in Next Generation Networks

Transcription

1 Platfrm fr Cntrl and Delivery f services in Next Generatin Netwrks DELIVERABLE 3.1 Design f the prttype

2 PROPRIETARY INFORMATION CEFRIEL 2008 All Rights Reserved PliTO 2008 All Rights Reserved This dcument and the data included in this dcument is prprietary t CEFRIEL and Trin s plytechnic, and is nt t be reprduced, used, r disclsed in whle r in part t anyne withut the express written permissin f the parts abve. The cntent f this dcument is prvided fr infrmatinal use nly and is subject t change withut ntice. Questins abut this dcument r the features it describes shuld be directed t: CEFRIEL

3 RECORD OF CHANGES Versin Date Descriptin /10/2008 First versin /10/2009 Dcument Revisin

4 Index Index Intrductin Prttype Descriptin IMS Architecture Hme Subscriber Server (HSS) Call Sessin Cntrl Functin (CSCF) IMS cmplementary prtcls PICO Demnstratr Architecture descriptin Public Safety Cmmunicatins Device (PSCD) Public Safety Cmmunicatin Server (PSCS) Mbility Applicatins On Demand EMS Applicatins LE Applicatins FF Applicatins Use Cases Typical Use Case Authenticatin IMS Presence subscriptin prcedure Lgin & Authenticatin Chse Applicatin n demand... 39

5 3.1.5 Run Applicatin Delete Applicatin Prttype technlgies Operating system: Ggle Andrid Applicatins Applicatin Framewrk Libraries Andrid Runtime Linux Kernel Other Features Andrid Maps API IP Multimedia Subsystem IMS platfrms verview IMS clients Selected PICO technlgies PICO Server (PSCDS) PICO Client (PSCD) LST: A prtcl fr mapping Gegraphic lcatins t public safety answering pints 50 Table f Acrnyms Index f Figures Bibligraphy... 56

6 1 Intrductin 1.1 Rich cmmunicatin The main purpse f mbile cmmunicatins ver the past years has been t bring text, audi and vide n mbile devices. Recently, several initiatives have been made t enrich the experience f cmmunicatin between devices. One f these is the RCS (Rich Cmmunicatin Suite) mved t a GSMA (GSM Assciatin) wrk prgram which will add sme additinal features t the traditinal cmmunicatin. The aim can be summarized in three gals: Enhanced Phnebk Enhanced Messaging Enriched Call The achievement f these gals intrduces the cncept f presence infrmatin, image and vide sharing, instant messaging, and ther services. T bring these additinal services, RCS uses the IMS (IP Multimedia Subsystem) framewrk. 1.2 IP Multimedia Subsystem The IP Multimedia Subsystem (IMS) is a framewrk fr delivering IP multimedia services ver CS (Circuit Switch) netwrks (e.g. GSM, LTE ). The aim is t bring Internet services in mbile netwrks making interperable and transparent the circuit switch and packet netwrk. Mainly t satisfy sme f these needs, IMS uses SIP and ther prtcls such as (SIMPLE, XCAP, MSRP, etc.). 1.3 PICO Gals The prject PICO aims t study innvative telecm services fr service delivery n large bandwidth netwrks, fcusing n cnvergence between fixed- mbile phne netwrks and n technlgies fr service creatin, prvisining, and management. The main prject gal is the study and experimentatin f innvative service delivery fr fixed- mbile cnvergence based n IMS platfrm; the cmplex IMS structure must be adapted and extended t prvide access t fix and mbile telecm peratrs.

7 The specific gals cnsist in the implementatin f a prttype and analysis f the features ffered by IMS system fr "cntext- aware" applicatin streaming, and, in general, in remte applicatins usage by means f a virtual access t different prtcls cmpliant with IMS system. This deliverable cntains a descriptin f the prttype, an analysis f all cmpnents that frm a cmplete device, bth frm a lgical view and a physical view. In this deliverable we als intrduce a use case ntatin that better explains the interactin between the different actrs f the prttype (user device, IMS subsystem, applicatin server, etc.). The last paragraph is dedicated t the technical specificatins f hw the prttype can be develped and technical suggestins f new technlgies that help the develpment f ur prttype.

8 2 Prttype Descriptin In the scenaris described in the deliverable [1], ur prttype can be viewed as set up by tw different elements, ne with the rle f the client and ne with the rle f the server. Our attentin is fcused n the client device, which is used by a human user: an Emergency Medical Services User (EMS), a Fire Fighters (FF) r a Law Enfrcement Agent (LE). This device transmits with an applicatin server belnging t IP Multimedia Subsystem; the server manages all the infrmatin regarding the different users f the system, prfiles, resurce access grants, and allws the authenticated user fr dwnlad f an applicatin amng the dwnladable set. The fllwing figure (Figure 1) describes the human actrs wrking n this scenari. Figure 1: Actrs All the users have a different prfile based n their user type, fr instance a nrmal paramedic will be granted a infrmatin access restricted prfile; he wuld be allwed t dwnlad a base applicatin (an applicatin that allws a vide- cnference with paramedics, cardilgist and pisn team), r an applicatin that allws the access t the database f the nearby hspitals (read access nly), r wuld be allwed t call fr help the Emergency Operatins Center (EOC).

9 A manager f the Incident Cmmand Team instead will be granted a brader set f applicatin dwnladable applicatins and infrmatin, such as an applicatin that allws enabling r disabling the traffic lights, thrugh he can view the different visin f all the team s camera. In the deliverable [1] we analyzed tw types f scenari, ne with specific cntext where all the peple that wrk in this cntext belng at the same grup (Emergency Medical Services (EMS), Fire Fighters (FF) and Law Enfrcement (LE)) and the ther ne where users belng t mre different grups, suppsed n cperatin. In detail: An hmgenus grup: EMS Wrkfrce Team r FF Wrkfrce Team r LE Wrkfrce Team A hetergeneus grup: all type f Public Safety Cmmunicatin Device Users (EMS, FF and LE) can wrk tgether; this grup is called Incident Cmmand Team. This is summarized in Figure 2. Figure 2: Interdisciplinary grup

10 The fllwing paragraphs describes: the IMS architecture, the basic PICO demnstratr, the main dwnladable applicatins; we pint ut the interactin f different IMS architectures and the mbility case (hme netwrk and visited netwrk). 2.1 IMS Architecture This paragraph describes IMS architecture frm the pint f view f ur prttype; then we pint ut the main elements that set up the cre architecture. The IMS (IP Multimedia Subsystem) technlgy is the key element in the 3G and NGN (Next Generatin Netwrks) architectures that will merge the Internet with the cellular wrld. It will make pssible t prvide ubiquitus cellular access t all the services that the Internet prvides, s that internet technlgies, such as the web, , instant messaging, presence, and videcnferencing will be available nearly everywhere. IMS fills the gap between the tw mst successful cmmunicatin paradigms, cellular and Internet technlgy. Befre starting t explain IMS architecture in detail, we re ging t have a view f the IMS basic principles that are interesting fr ur structure. IMS enables access independence. This means that all existing netwrks culd wrk with IMS, thrugh apprpriate gateways and interfaces, in rder f the layer cnsidered. IMS wrks with terminal and user mbility. IMS allws peratrs and service prviders t use different underlying netwrk architecture. IMS ffers extensive IP- based services, such as VOIP (Vice ver IP), POC (Push t talk Over Cellular), multiparty gaming, videcnferencing, presence infrmatin, instant messaging, cntent sharing, and s n. T satisfy the requirement impsed frm IMS features, a layered architecture was selected fr this architectural framewrk. Frm bttm t up, in IMS layered architecture we have: Access plane, Cntrl plane and Applicatins plane. Access plane achieves the cnnectin f all users t IMS cre netwrk. This is made directly if the user emplys an IMS terminal, and thrugh gateways if the device is nt IMS. Gateways emply standard interfaces that make it pssible cmmunicating with all existing entities. This layer is hence directly respnsible fr carrying the traffic between endpints. Cntrl plane has as cre ccupatin the Call Sessin Cntrl Functin (CSCF). This functin is reached by sharing the cntrl between three different entities: Prxy, Serving and Interrgating. We re ging t analyze them in detail further n. Applicatins plane hsts and executes services (IP applicatins), and delivers them using SIP t interface with the Cntrl layer. Nw we can g beynd this verview analyzing in detail parts that are interesting in ur structure based n IMS architecture. We begin by explaining all the elements that appear in the fllwing figure (see Figure 3).

11 2.1.1 Hme Subscriber Server (HSS) Figure 3: IMS architecture HSS is the main database supprting IMS architecture entities respnsible fr call r sessin management. HSS cntains all the infrmatin abut user prfile and manages authenticatin and authrizatin at IMS level and can prvide infrmatin abut physical psitin f the user. Infrmatin abut user prfile includes user identity, allcated S- CSCF name (see the S- CSCF paragraph), raming prfile, authenticatin parameters and service infrmatin. User identities can be private r public. The private user identity is assigned by the hme netwrk peratr and is used fr such purpse as registratin and authrizatin, while the public user can be used frm ther user fr requesting cmmunicatin with the end user. HSS als prvides the traditinal Hme Lcatin Register (HLR) and Authenticatin Centre (AUC) functins, required by the PS dmain and the CS dmain. Depending n several factrs, like number f mbile subscribers, capacity f the equipment and netwrk rganizatin, there may be mre than ne HSS per hme netwrk. In case f multiple HSS, a Subscriber Lcatin Functin (SLF) is needed t map user addresses t enable I- CSCF, P- CSCF and AS t find the address f the HSS hlding the required user- specific data. Bth HSS and SLF cmmunicate thrugh Diameter prtcl Call Sessin Cntrl Functin (CSCF) Prcessing SIP signaling packets in the IMS is achieved by using a grup f entities that we culd call the sessin management and ruting family. This family cnsists f three entities: Prxy CSCF (P- CSCF), Interrgating CSCF (I- CSCF), and Serving CSCF (S- CSCF).

12 P- CSCF The first pint f cntact fr users within IMS is P- CSCF. It perfrms a stateful SIP prxy, all the traffic frm/t end users passes thrugh this entity. The P- CSCF validates the request, frwards it t selected destinatins and prcesses and frwards the respnse. It perfrms user authenticatin, can establish a secure sessin IPsec with IMS terminals and supprts Resurce Admissin Cntrl functinalities. In additin, it may behave as a User Agent, which rle is needed fr releasing sessin in abnrmal cnditins and fr generating independent SIP transactins. In ne peratr netwrk there can be ne r many P- CSCF. The terminal discver its P- CSCF using DHCP r, in GPRS, PDP Cntext. When an IMS terminal is assigned t a P- CSCF this assciatin des nt change during the validity perid f the registratin. We re ging t see each functin in detail: Frwards SIP register requests t I- CSCF based n a hme dmain name prvided by the user in the request, and ther requests and respnses received by the user t S- CSCF. Detects emergency sessin establishment requests. Sends accunting related infrmatin t the Charging Cllectin Functin (CCF). Prvides integrity prtectin f SIP signaling and maintain an IPsec security assciatin with user. Can make cmpressin f SIP messages t reduce the rund trip time ver critical links. Executes media plicing, checking the cntent f the SDP paylad (SDP: Sessin Descriptin Prtcl) t ensure the media is allwed fr the user. Maintains sessin timers. It can detect a free resurces used up by hanging sessins. Interacts with Plicy Decisin Functin (PDF), which can als be included in P- CSCF. PDF is respnsible f authrizatins plicy n media plane infrmatin btained frm P- CSCF. This functin takes a service level plicy request frm the applicatin layer and translates it int IP QS parameters. Can prvide defenses against SIP signaling attacks I- CSCF It s a stateless SIP prxy placed n the edges f an administrative dmain and it s a cntact pint fr all cnnectins destined t a user actually raming in a different peratr netwrk. It s the entity that is able t determine the S- CSCF with which a user shuld register. This is achieved by querying the HSS. The I- CSCF can be remved frm the signaling path nce it has been used t establish which S- CSCF is in use. The I- CSCF IP address is published in the Dmain Name System (DNS) f the dmain, s that remte servers can find it and use it as a frwarding pint. Up t release 6, I- CSCF can als be used t hide tplgy, capacity and cnfiguratin f the internal netwrk frm the utside wrld (functin THIG), but frm release 7 this functin is part f the Intercnnectin Brder Cntrl Functin (IBCF). IBCF rles include the prvisin f NAT and Firewall functins fr signaling, plicing f signaling, tplgy hiding and cnversin between IPv4 and IPv6. It als cntrls the media exchanged acrss the peratr bundary S- CSCF It s the brain f the IMS. This entity registers the users and prvides services t them. It perfrms multimedia sessin setup, changing and release; ruting, translatin, prvides billing infrmatin t

13 media systems, interrgates HSS t retrieve authrizatin, service triggering infrmatin and user prfile, using Diameter prtcl. It has n lcal strage f the user. It s a SIP server, always lcated in the hme netwrk. During the sessin setup it can mnitr SDP t ensure the sessin respects user prfile edges. In detail, the functinalities perfrmed by the S- CSCF are: Handling registratin request; it knws the user IP address and which P- CSCF is using as IMS entry pint. User registratin and de- registratin (with registratin timer supervisin) and authenticatin by means f the IMS Authenticatin and Key Agreement schema. Dwnlad f user infrmatin and service related data frm HSS when necessary. Ruting f mbile- terminating traffic t P- CSCF and f mbile- riginated traffic t I- CSCF, BGCF r AS. Sessin cntrl with capability t decide when a request must be further prcessed by ruting t an AS, that is interactin with service platfrms. Translatin f E.164 numbers t SIP URI needed frm SIP signaling ruting. Media plicing checking SDP paylad. Supprting f emergency sessins. Sending f accunting- related infrmatin t the Charging Cllectin Functin (CCF). 2.2 IMS cmplementary prtcls Lately we are seeing an expnential grwth f mbile applicatins and that s transfrming the mbile market mre and mre applicatin centric. The enrmus grwth we are seeing f mbile applicatin stres (e.g. Apple Stre, Andrid Market, etc.) is an example that the cmmunicatin is nt limited just t the text, audi r vide but a cmmunicatin between applicatins. IMS implements the MSRP 1 prtcl fr the exchange f files. It is based n SIP and can exist nly if a SIP Sessin has been established. It uses SDP prtcl t describe all the exchange parameters between tw endpints. An extract f an SDP Message descriptin is shwn belw: v=0 =pic IN IP4 picserver.cefriel.it s= - c=in IP4 picserver.cefriel.it t=0 0 m=message 7394 TCP/MSRP * a=accept- types:text/plain a=path:msrp://picserver.cefriel.it:7394/3f67i7ea2b;tcp 1 MSRP: (Message Sessin Relay Prtcl - RFC ) : is a prtcl fr transmitting files ver SIP

14 SDP prtcl cntains all the details t rute cmmunicatin ver TCP. MSRP Prtcl is nt yet widely used and althugh it allws transferring files, a lack f it s far is the full supprt f the applicatin sharing, managing and pssibly, cmmunicatin between them. 2.3 PICO Demnstratr In the cntext f IMS Architecture described in the paragraph 2.1, ur prttype is cmpsed by tw different parts (see Figure 4): User device named Public Safety Cmmunicatins Device (PSCD): a next generatin device, it is the peratrs equipment that allws user t use the IMS subsystem and yur services; Applicatin Server named Public Safety Cmmunicatin Server (PSCS): an applicatin server that belngs t the IP Multimedia Subsystem, and perfrms the functinalities f: authenticatin and authrizatin f users based n their prfiles, mbility handling, applicatin n demand handling. Bth PSCD and PSCS must be authenticated by IP Multimedia Subsystem, and cmmunicatin is based n: SIP prtcl MSRP prtcl CnteXML Other prtcl t be defined

15 Figure 4: PICO demnstratr The fllwing paragraphs describe the PSCD and PSCS n the pint f view f lgical view and physical view Architecture descriptin As described abve, PICO architecture is based n IMS Framewrk. The PCSDS is an applicatin which perfrms an IMS registratin and is cnsidered in the system as a Rbt. All PSCD users using a PICO client (extended IMS client) are registered t the IMS as well fr the gegraphical area pertaining t the PICO server. Each user has PICO rbt (PSCDS) as buddy 2 and peridically sends 3 its cntext using MSRP prtcl and the IMS- SIP sessin. The cntext is a XML File (CnteXML 4 ) which cntains several cntexts infrmatin such as user lcatin, battery level, disk usage, type f user and s n. PICO Server prcesses the cntext f all users in a specific area and als analyzing the cntext f emergencies, it perfrms reasning t ffer r send relevant cntext applicatin. 2 Buddy: A friend r cntact added t the cntact list/phne bk 3 The frequency f delivery depends n PCDS lcatin and frm emergencies in a specific area 4 CnteXML: Extended XML file with cntextual parameters

16 PICO server (PSCDS) uses a rule engine (reasner) and sme preset rules t perfrm his actins. The applicatin are exchanged, rganized and installed using the MSRV prtcl and this extends the IMS platfrm with full applicatin supprt Public Safety Cmmunicatins Device (PSCD) A Public Safety Cmmunicatins Device is a generalizatin f a particular device f each type f user: a Law Enfrcement Public Safety Cmmunicatins Device, Fire Fighters Public Safety Cmmunicatins Device and Emergency Medical Services Public Safety Cmmunicatins Device. This is illustrated in Figure 5. Figure 5: PSCD generalizatin

17 In the deliverable [1] we analyzed emergency scenaris and we saw the imprtance f applicatin delivery and the peratrs equipment during such a situatin. The applicatin and services deplyment needs t be as fast as pssible and the peratrs devices need t be small and prtable. In the deliverable [2] we presented the available technlgies regarding the applicatin n demand service; n the ther hand, the aim f this chapter is t prvide a full verview f the available mbile devices including perating systems. We present indeed the mst imprtant envirnment regarding the develpment f sftware fr small devices, we will present the perating systems and we will give a brief verview cncerning the mst imprtant current devices. Each Public Safety Cmmunicatins Device is a device f next generatin and it must have mre additinal equipment (see Figure 6) t perfrm all the services required. The device must have, at least: a vide camera t perfrm videcnferencing and allwing recrding user sights ccurred during his presence; a micrphne t perfrm audi calls; a GPS device t perfrm the ge- lcatin. Mrever, the device culd have an additinal subset f sensrs in rder t perfrm registratin f vital parameters, fr example the EKG unit, a respiratr mnitr, and a bld pressure mnitr. The prtable device f every paramedic culd mnitr vital signals but als analyze bld and chemical air cmpsitin, and als the substances that intxicated the patient. Streaming is helpful because, in case f need, the paramedics culd enable the plug in fr streaming, fr analysis purpses. Figure 6: PSCD required and ptinal equipment

18 A lgical view f the PSCD is described in Figure 7, which identifies five main blcks (r subsystems): IMS client: This subsystem is respnsible fr implementing all the IMS client features required by the PSCD. Mst imprtant IMS features here supprted are user authenticatin t the IMS, audi/vide call setup, presence service and IM. Mre generally, the IMS client manages all the multimedia sessins required by the PSCD. IMS client exprts a prper set f APIs t the ther PSCD subsystems. Mrever IMS client implements the MSRP prtcl t allw file transfer, and mre precisely it prvides the applicatin transfer frm PSCD Server. Base Features: This subsystem is the cre f the PSCD User Driven Applicatins: This subsystem cllects all the applicatins required by the PSCD during peratins and that are specified t the user prfiles and needs Device Driven applicatins: This subsystem cllects all the applicatins required by the PSCD during peratins and that are specified t the device type and the equipment installed n it. Each User after IMS authenticatin and Public Safety Cmmunicatin Server authrizatin reaches his wn hme page where he can chse which Applicatin On demand he culd dwnlad. Figure 7: PSCD internal view

19 As described in chapter 2.3.1, PICO Client r PSCD is an extended IMS Client. It prvides all SIP functinalities such as: Audi call Vide call Chat Applicatin transfer (file transfer) This type f cmmunicatins can be established amng users r between Pic client and Pic server. In fact, it peridically sends it cntext (based n lcatin, battery life..) using a CnteXML file t the Pic Server (PSCDS) t receive the updates (ntificatins r applicatins) Public Safety Cmmunicatin Server (PSCS) The Public Safety Cmmunicatin Server (PSCS) is the server f the PICO demnstratr and it enables t the PSCD the access t the PICO services and applicatins. We can see the PSCS as an applicatin server f the IMS but we can als identify it as a client f the IMS with special functins. Figure 8: Public Safety Cmmunicatin Server The Figure 8 shws the internal view f Public Safety Cmmunicatin Server. It is made up by different elements: User Prfile: all the users have a user prfile that describes the cnfiguratin fr a specific user, including the user's access permissin fr the applicatins n demand, user type (FF, LE r EMS) and preferences settings.

20 Service Authrizatins: this mdule sets the authrizatin fr the service required at each user level. Dwnladable Applicatins: these are the dwnladable applicatins n demand. Online Applicatins: these are the applicatins n demand that are directly n line when the user perfrm authenticatin. Stream Applicatins: applicatins that can be streamed n demand. Mbility: this mdule manages mbility amng the three IMS architectures (FF Netwrk, LE Netwrk and EMS Netwrk). Cre framewrk: this mdule perfrms all the basic functinalities. IMS client: this mdule perfrms the functinality f IMS client allwing: registratin n IMS, invite a sessin, file transfer using MSRP prtcl and s n. Reasner: this mdule perfrms reasning based n rules that cnsider emergencies fr a specific area and all users near that area. Cntext: this mdule manages all Cntext parameters based n (GEO Crdinates f the PSCD Users, the battery level f the device, netwrk traffic and s n. Figure 8 describe a specific cnfiguratin f the PICO architecture where it is pssible t identify a hierarchy f PSCS that enables cllabratin between the different PSCS belnging t different Public Safety grups (FF, LE, and EM). It is imprtant t ntice that PSCS synchrnizatin is nt cnsidered in the PICO prject.

21 Figure 9: IMS Hierarchical Netwrk

22 2.4 Mbility In the scenari f IMS Internetwrking (Figure 10) there are three different IMS netwrks, ne f Fire Fighter, ne f Law Enfrcement and ne f Emergency Medical Services. Each user has its hme netwrk, but we suppsed that in the lcatin f the emergency scenari nt all the three netwrks can be reached. Figure 10: IMS Internetwrking Cnsider a scenari where Fire Fighter access netwrk is nt reachable. Fire Fighter PSCD can register itself t the Law Enfrcement Netwrk that is cnnected with fire fighter hme netwrk. In this case the authrizatin and authenticatin is perfrmed by a FF Public Safety Cmmunicatins Server.

23 Figure 11: PICO mbility 2.5 Applicatins On Demand Anther aspect t be managed in an applicatin- centric netwrk is the cntext f applicatin. Assumed that the framewrk is extended fr the applicatin sharing (actually is ne f the gals f PICO), the perating system shuld handle the applicatins that culd be installed nt device. Many are the cntextual parameters that culd be analyzed fr each device when an applicatin starts dwnlading, fr instance:

24 Disk usage Lcatin Battery Level Netwrk traffic Cnsidering these parameters, an applicatin culd be dwnladed r nt, r in case f lw disk space, a lite versin f an applicatin culd be dwnladed instead f full versin, r an applicatin with less media usage instead f full media in case f lw battery/bad netwrk. PICO already takes care f all these assumptins adding mre cntext parameters such as: User accunt and privileges Existing emergencies in a gegraphical area Status and prximity f neighbrs (Paramedics, FF and Plice) This paragraph describes the pssible applicatins n demand that a user can chse amng the available applicatins, then dwnlad and run lcally We have divided the applicatins int different classes; three classes are specific fr type f user (EMS Applicatins, LE Applicatins and FF Applicatins), the ther classes are instead shared by all the users (Wrkfrce, Incident Cmmand and On bard resurces status). The Figure 12 describes the classificatin f applicatins n demand.

25 Figure 12: Applicatins n demand The Wrkfrce applicatin is the main applicatin, when all the users belng t the same grup (r EMS r LE r FF), which perfrms the fllwing functinalities: Online wrkfrce n Ggle Maps; Online wrkfrce inside building (using building maps if available); User exprted services (depends n prfile and device features); Alarm ntificatin (e.g. fire fighter in trubles, etc.); Start cmmunicatin (audi, vide, chat); Create cllabratin sessins; Filter fr specific user rles; Filter fr specific device features; Incident ht znes (red, green) and identificatin f risk's type (cntaminatin, fire, etc.). The Incident cmmand applicatin is the main applicatin in case f different type f users present n the incident place, in this case where there are interdisciplinary grup. This applicatin perfrms the fllwing functinalities: Gruping Functinality: the ability t create an interdisciplinary grup t put in tuch dissimilar user n incident site; Wrkfrce Interperability: fill user grup n the Map (Allcatin f all grup f user n the map with its psitin and available services); Vide, Vice and Chat cmmunicatin between users f the grups; List f all services exprted by users (Textual); Bradcast Messages:

26 Emergency Buttn t ask fr help. The On Bard Resurces Status applicatin perfrms a cntinual and up t date status f all n bard resurces (Inventry, available cams, sensrs, and s n). The fllwing paragraphs describe the specific applicatin: EMS applicatins, LA applicatins and FF applicatins EMS Applicatins These applicatins are specific applicatins f Emergency Medical Services Users and they are divided int three categries: EMS training: the user can dwnlad emergency prcedures frm surces (as instructinal aides f pisn center and ther instructin f EMS training packages). Case Histry: when a user acquires persnal infrmatin abut the patient he can dwnlad an applicatin t view a histry f the patient (previus hspitalize, pssible allergy, etc.) Hspital list: the user can dwnlad an applicatin t view a list f available hspitals, the distance frm the incident lcatin and all the available services LE Applicatins These applicatins are specific applicatins f Law Enfrcement Users and are divided int fur categries: Vehicle Stp Functin: is a special applicatin that is active when the plice identified a suspect vehicle. Vehicle psitin is sent in Central statin; Vehicle s data is cllected thrugh place recgnitin and displayed n device, mrever vide camera n the fficer s vehicle dashbard begins recrding vide f the vehicle that can be accessed at any time, n- demand, by the authrized PSCDU users. Arrest prcedure: cllects all infrmatin abut the persn arrested (The PSCD submits the scan data t the bimetric ID database fr identificatin). Then the infrmatin will be used by transprt unit fr transprt him t the prisn. Mrever this infrmatin will be used by tw truck fr vehicle transprtatin and tw reprt. Mtr Vehicle Registratin: allws access t the MVR Database t get as much detail as pssible n the vehicle. All infrmatin will be displayed directly n the PSCDU device. Criminal Recrd: allws access t the CR Database t get as much detail as pssible n the persn. All infrmatin will be displayed directly n the PSCDU device FF Applicatins These applicatins are specific applicatins f Fire Fighters Users and they are divided int tw categries:

27 FF Emergency: is an applicatin that autmatically (thrugh risk recgnitin) r manually (thrugh PSCDU buttn) cmmunicates with paramedics r ther FF, a state f emergency FF Life Mnitr: thrugh this applicatin, in an Incident Area Netwrk, the EMS unit utside the apartments mnitrs the vital signs f all the firefighters in and arund the fire scene.

28 3 Use Cases This chapter cntains a sequence diagram f a typical PICO Applicatin use case and an example f applicatin n demand the spatial lcalizatin. 3.1 Typical Use Case The fllwing figure describes a typical use case f PICO Applicatin. The first step is the authenticatin (see 3.1.1) f the user and f the server n IP Multimedia Subsystem. This peratin is perfrmed at the hme netwrk r, in case f wn access netwrk is nt reachable, at the visited netwrk. Figure 13: Main Use Case After registratin t IP Multimedia Subsystem (IMS) f bth the active element (Public Safety Cmmunicatin Device and Public Safety Cmmunicatin Server) PSCS perfrms the presence subscriptin prcedure. In this dcument we als describe prcess f PSCD presence update (see 3.1.2). Subsequently the user perfrms the applicatin server authenticatin (see 3.1.3) by a sip invite message and a PICO Applicatin hme page is shwed.

29 After Lgin t the PICO Applicatin, the user can view a list f dwnladable applicatins and hence chse ne (3.1.4). When dwnlad is cmpleted, the user can lcally run the applicatin (3.1.5) and subsequently delete it (3.1.6). The fllwing paragraphs describe these steps Authenticatin IMS Bth the entities (PSCD and PSCS) are client f IP Multimedia Subsystem and they must perfrm authenticatin n IMS. This is perfrmed by a sip message (register) and there are tw scenaris, ne when the user perfrms authenticatin n the wn access netwrk and ne when the wn access netwrk is nt reachable and the user perfrms authenticatin at a visited netwrk. The mst simple scenari is when the wn access netwrk is reachable and the user (fr example a Fire Fighter user) can register itself t the Hme Netwrk. The Figure 14 describes this scenari. Bth Public Safety Cmmunicatin Device (PSCD) and Public Safety Cmmunicatin Server (PSCS) perfrm a registratin with Registrar Server (belngs t IP Multimedia Subsystem).

30 Figure 14: Authenticatin IMS - n mbility In case f user wn access netwrk is nt reachable, the visited netwrk frwards all the messages f user t his hme netwrk. This scenari is described by a Figure 15.

31 Figure 15: Authenticatin IMS mbility In all scenaris the authenticatin prcedure is perfrmed by a REGISTER Message; it is a SIP message described in the fllwing paragraph REGISTER Message REGISTER requests add, remve, and query bindings. A REGISTER request can add a new binding between an address- f- recrd and ne r mre cntact addresses. Registratin n behalf f a particular address- f- recrd can be perfrmed by a suitably authrized third party. A client can als remve previus bindings r query t determine which bindings are currently in place fr an address- f recrd.

32 The fllwing header fields, except Cntact, must be included in a REGISTER request. A Cntact header field may be included: Request- URI: The Request- URI names the dmain f the lcatin service fr which the registratin is meant (fr example, "sip: chicag.cm"). The "userinf" and "@" cmpnents f the SIP URI must nt be present. T: The T header field cntains the address f recrd whse registratin is t be created, queried, r mdified. The T header field and the Request- URI field typically differ, as the frmer cntains a user name. This address- f- recrd MUST be a SIP URI r SIPS URI. Frm: The Frm header field cntains the address- f- recrd f the persn respnsible fr the registratin. The value is the same as the T header field unless the request is a third- party registratin. Call- ID: All registratins frm a UAC shuld use the same Call- ID header field value fr registratins sent t a particular registrar. If the same client were t use different Call- ID values, a registrar culd nt detect whether a delayed REGISTER request might have arrived ut f rder. CSeq: The CSeq value guarantees prper rdering f REGISTER requests. A UA MUST increment the CSeq value by ne fr each REGISTER request with the same Call- ID. Cntact: REGISTER requests MAY cntain a Cntact header field with zer r mre values cntaining address bindings. A registrar is a user agent server that respnds t REGISTER requests and maintains a list f bindings that are accessible t prxy servers and redirect servers within its administrative dmain. A registrar has t knw (fr example, thrugh cnfiguratin) the set f dmain(s) fr which it maintains bindings. REGISTER requests must be prcessed by a registrar in the rder that they are received. REGISTER requests must als be prcessed atmically, meaning that a particular REGISTER request is either prcessed cmpletely r nt at all. Each REGISTER message must be prcessed independently f any ther registratin r binding changes. When receiving a REGISTER request, a registrar fllws these steps: The registrar inspects the Request- URI t determine whether it has access t bindings fr the dmain identified in the Request- URI. If nt, and if the server als acts as a prxy server, the server shuld frward the request t the addressed dmain, fllwing the general behavir fr prxying messages (fr details see specificatin SIP specificatin [3]). A registrar shuld authenticate the user agent client. Mechanisms fr the authenticatin f SIP user agents are described in SIP specificatin [3]. The registrar extracts the address- f- recrd frm the T header field f the request. If the address- f- recrd is nt valid fr the dmain in the Request- URI, the registrar sends a404 (Nt Fund) respnse and skips the remaining steps. The registrar checks whether the request cntains the Cntact header field. If nt, it skips t the last step. If the Cntact header field is present, the registrar checks if there is ne Cntact field value that cntains the special value "*" and an Expires field. If the request has additinal Cntact fields r an expiratin time ther than zer, the request is invalid, and the server returns a 400 (Invalid Request) and skip the remaining steps. If nt, the registrar checks whether the Call- ID agrees with the

33 value stred fr each binding. If nt, it remves the binding. If it des agree, it remves the binding nly if the CSeq in the request is higher than the value stred fr that binding. Otherwise, the update must be abrted and the request fails. The registrar nw prcesses each cntact address in the Cntact header field in turn. Fr each address, it determines the expiratin interval as fllws: If the field value has an "expires" parameter, that value must be taken as the requested expiratin. If there is n such parameter, but the request has an Expires header field, that value must be taken as the requested expiratin. If there is neither, a lcally- cnfigured default value must be taken as the requested expiratin. Fr each address, the registrar then searches the list f current bindings using the URI cmparisn rules. If the binding des nt exist, it is tentatively added. If the binding des exist, the registrar checks the Call- ID value. If the Call- ID value in the existing binding differs frm the Call- ID value in the request, the binding must be remved if the expiratin time is zer and updated therwise. If they are the same, the registrar cmpares the CSeq value. If the value is higher than that f the existing binding, it must update r remve the binding as abve. If nt, the update must be abrted and the request fails. This algrithm ensures that ut- f- rder requests frm the same user agent are ignred. Each binding recrd recrds the Call- ID and CSeq values frm the request. The binding updates must be cmmitted (that is, made visible t the prxy r redirect server) if and nly if all binding updates and additins succeed. The request fails with a 500 (Server Errr) respnse and all tentative binding updates must be remved when any ne f them fails (fr example, because the back- end database cmmit failed) Presence subscriptin prcedure The presence subscriptin has mre imprtance fr Wrkfrce r Incident Cmmand applicatins, a server PSCS culd subscribe at all the event f presence fr all the users that are in t the place f incident. The presence service serves t accept infrmatin, stre it, and distribute it. The infrmatin stred is (unsurprisingly) presence infrmatin. The presence service has tw distinct sets f "clients": ne set f clients, called presentities, prvides presence infrmatin t be stred and distributed. The ther set f clients, called watchers, receives presence infrmatin frm the service. There are tw kinds f watchers, called fetchers and subscribers. A fetcher simply requests the current value f sme presentity s presence infrmatin frm the presence service. In cntrast, a subscriber requests ntificatin frm the presence service f (future) changes in sme presentity s presence infrmatin. The prcedure is simpler and is described by Figure 16.

34 Figure 16: Flw f messages SUBSCRIBE The fllwing paragraphs described all the SIP messages used t perfrm this prcedure. The Figure 17 describes a sequence diagram fr subscriptin prcedure f PICO Applicatin.

35 Figure 17: Presence service SUBSCRIBE Message The ability t request asynchrnus ntificatin f events prves useful in many types f SIP services fr which cperatin between end- ndes is required. The general cncept is that entities in the netwrk can subscribe t resurce r call state fr varius resurces r calls in the netwrk, and thse entities (r entities acting n their behalf) can send ntificatins when thse states change. A typical flw f messages wuld be that shws by the Figure 16. "SUBSCRIBE" is added t the definitin f the element "Methd" in the SIP message grammar. The SUBSCRIBE methd is used t request current state and state updates frm a remte nde.

36 SUBSCRIBE requests shuld cntain an "Expires" header (defined in SIP [3]). This expires value indicates the duratin f the subscriptin. In rder t keep subscriptins effective beynd the duratin cmmunicated in the "Expires" header, subscribers need t refresh subscriptins n a peridic basis using a new SUBSCRIBE message n the same dialg as defined in SIP [3]. If n "Expires" header is present in a SUBSCRIBE request, the implied default is defined by the event package being used. Ntifiers may als wish t cancel subscriptins t events; this is useful, fr example, when the resurce t which a subscriptin refers is n lnger available (fr mre details see specificatin [4]). Identificatin f events is prvided by three pieces f infrmatin: Request URI: cntains enugh infrmatin t rute the request t the apprpriate entity per the request ruting prcedures utlined in SIP [3]. It als cntains enugh infrmatin t identify the resurce fr which event ntificatin is desired, but nt necessarily enugh infrmatin t uniquely identify the nature f the event (e.g., "sip:adam@dynamicsft.cm" wuld be an apprpriate URI t subscribe t fr my presence state; it wuld als be an apprpriate URI t subscribe t the state f my vice mailbx). Event Type: Subscribers include exactly ne "Event" header in SUBSCRIBE requests, indicating t which event r class f events they are subscribing. The "Event" header will cntain a tken which indicates the type f state fr which a subscriptin is being requested. This tken will be registered with the IANA and will crrespnd t an event package which further describes the semantics f the event r event class. The "Event" header may als cntain an "id" parameter. This "id" parameter, if present, cntains an paque tken which identifies the specific subscriptin within a dialg. An "id" parameter is nly valid within the scpe f a single dialg. (ptinally) message bdy: If the event package t which the event tken crrespnds defines behavir assciated with the bdy f its SUBSCRIBE requests, thse semantics apply. An example f SUBSCRIBE message in PICO Applicatin is described by Figure 17 (zm image SUBSCRIBE) NOTIFY Message NOTIFY messages are sent t infrm subscribers f changes in state (see Figure 16) t which the subscriber has a subscriptin. Subscriptins are typically put in place using the SUBSCRIBE methd; hwever, it is pssible that ther means have been used. A NOTIFY des nt terminate its crrespnding subscriptin; in ther wrds, a single SUBSCRIBE request may trigger several NOTIFY requests. Identificatin f events being reprted in a ntificatin is very similar t that described fr subscriptin t events (see ). As in SUBSCRIBE requests, NOTIFY "Event" headers will cntain a single event package name fr which a ntificatin is being generated. The package name in the "Event" header must match the Event" header in the crrespnding SUBSCRIBE message. If an "id" parameter was present in the

37 SUBSCRIBE message, that "id" parameter must als be present in the crrespnding NOTIFY messages. Event packages may define semantics assciated with the bdy f their NOTIFY requests; if they d s, thse semantics apply. NOTIFY bdies are expected t prvide additinal details abut the nature f the event which has ccurred and the resultant resurce state (t mre details see specificatin [4]). When a SUBSCRIBE request is answered with a 200- class respnse, the ntifier immediately cnstructs and sends a NOTIFY request t the subscriber. When a change in the subscribed state ccurs, the ntifier shuld immediately cnstruct and send a NOTIFY request, subject t authrizatin, lcal plicy, and thrttling cnsideratins. A NOTIFY request is cnsidered failed if the respnse times ut, r a nn- 200 class respnse cde is received which has n "Retry- After" header and n implied further actin which can be taken t retry the request PIDF The Presence Infrmatin Dcument Frmat (PIDF) specifies the baseline XML- based frmat fr describing presence infrmatin. One f the characteristics f the PIDF is that the dcument always needs t carry all presence infrmatin available fr the presentity. In sme envirnments where lw bandwidth and high latency links can exist, it is ften beneficial t limit the amunt f transprted infrmatin ver the netwrk. Fr details see specificatin [8] Lgin & Authenticatin The PSCD use INVITE SIP message t lgin at PSCS and after that a HTTP sessin is created and crrelated with the SIP sessin. A hme page is displayed t the user where he can chse which applicatin he culd dwnlad (see 3.1.4). The Figure 18 describes a flw between PSCD and PSCS.

38 Figure 18: Lgin and Authenticatin INVITE Message When a user agent (UA) client desires t initiate a sessin (fr example, audi, vide, r a game), it frmulates an INVITE request. The INVITE request asks a server t establish a sessin. This request may be frwarded by prxies, eventually arriving at ne r mre user agent server (UAS) that can ptentially accept the invitatin. These UASs will frequently need t query the user abut whether t accept the invitatin. After sme time, thse UASs can accept the invitatin (meaning the sessin is t be established) by sending a 2xx respnse. If the invitatin is nt accepted, a 3xx, 4xx, 5xx r 6xx respnse is sent, depending n the reasn fr the rejectin. A 2xx respnse t an INVITE establishes a sessin and it als creates a dialg between the UA that issued the INVITE and the UA that generated the 2xx respnse. Since the initial INVITE represents a request utside f a dialg, its cnstructin fllws the prcedures f request message (see specificatin [3]). SIP requests are distinguished by having a Request- Line fr a startline. A Request- Line cntains a methd name (INVITE), a Request- URI, and the prtcl versin separated by a single space (SP) character.

39 Request- URI: The Request- URI is a SIP r SIPS URI as described in specificatin [3]) r a general URI (RFC 2396 [9]). It indicates the user r service t which this request is being addressed. In case f INVITE message the initial Request- URI f the message is set t the value f the URI in the T field. SIP- Versin: Bth request and respnse messages include the versin f SIP in use, and fllw [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding versin rdering, cmpliance requirements, and upgrading f versin numbers. T be cmpliant with this specificatin, applicatins sending SIP messages must include a SIP- Versin f "SIP/2.0". A valid SIP request frmulated by a UAC must, at a minimum, cntain the fllwing header fields (all f these header fields are mandatry in all SIP requests): T: The T header field specifies the desired "lgical" recipient f the request, r the address- f- recrd (AOR) f the user r resurce that is the target f this request. There is n "tag" parameter since the dialg is nt established yet. Frm: The Frm header field indicates the lgical identity f the initiatr f the request, pssibly the user's address- f- recrd. The "tag" parameter identifies this UA as a peer f the dialg. CSeq: The CSeq header field serves as a way t identify and rder transactins. It cnsists f a sequence number and a methd, matching that f the request. Call- ID: The Call- ID header field acts as a unique identifier and must be the same fr all requests and respnses sent by either UA in a dialg. Max- Frwards: The Max- Frwards header field serves t limit the number f hps a request can transit n the way t its destinatin. It is decremented by ne at each hp. Via: The Via header field indicates the transprt (UDP) used fr the transactin and identifies the lcatin where the respnse is t be sent. The "branch" parameter is used t identify the transactin created by that request. It is mandatry and must always begin with the characters "z9hg4bk". Additinal prcessing is required fr the specific case f INVITE Chse Applicatin n demand When the PSCD cmpletes the btstrap and the user is authenticated by the PICO framewrk, the PSCD device will display the user the main applicatin page (PICO dashbard). This PICO dashbard displays the list f PICO applicatins available t the users depending n the cntext and device capabilities. These applicatins are nt usually available n the device but they must be dwnladed r streamed frm the PSCS. When user chses an applicatin the PICO framewrk will start the applicatin n the PSCS and stream it t the PSCD. In ther situatins, the PSCD will dwnlad the applicatin, fr example packed int a Java applet, r will start a web applicatin using web 2.0 (i.e. Ajax) architecture Run Applicatin When dwnlad is cmpleted, the user can unzip the file, if it is necessary, and lcally run the applicatin. The Figure 19 shws the interactin between user and PSCD.

40 Figure 19: Run Applicatin Delete Applicatin When the applicatin desn t already exist n the PSCD, the user can delete it (see Figure 20).

41 Figure 20: Delete Applicatin

42 4 Prttype technlgies 4.1 Operating system: Ggle Andrid Andrid is a sftware stack fr mbile devices that includes an perating system, middleware and key applicatins. The actual versin f Andrid SDK is a beta versin; it prvides the tls and APIs necessary t begin develping applicatins n the Andrid platfrm using the Java prgramming language. The fllwing diagram shws the majr cmpnents f the Andrid perating system, each sectin is described in mre detail belw. 4.2 Applicatins Figure 21: Ggle Andrid Andrid will ship with a set f cre applicatins including an client, SMS prgram, calendar, maps, brwser, cntacts, and thers. All applicatins are written using the Java prgramming language Applicatin Framewrk Develpers have full access t the same framewrk APIs used by the cre applicatins. The applicatin architecture is designed t simplify the reuse f cmpnents; any applicatin can publish its capabilities and any ther applicatin may then make use f thse capabilities (subject t security

43 cnstraints enfrced by the framewrk). This same mechanism allws cmpnents t be replaced by the user. Underlying all applicatins is a set f services and systems, including: A rich and extensible set f Views that can be used t build an applicatin, including lists, grids, text bxes, buttns, and even an embeddable web brwser Cntent Prviders that enable applicatins t access data frm ther applicatins (such as Cntacts), r t share their wn data A Resurce Manager, prviding access t nn- cde resurces such as lcalized strings, graphics, and layut files A Ntificatin Manager that enables all applicatins t display custm alerts in the status bar An Activity Manager that manages the life cycle f applicatins and prvides a cmmn navigatin back stack Libraries Andrid includes a set f C/C++ libraries used by varius cmpnents f the Andrid system. These capabilities are expsed t develpers thrugh the Andrid applicatin framewrk. Sme f the cre libraries are listed belw: System C library: a BSD- derived implementatin f the standard C system library (libc), tuned fr embedded Linux- based devices Media Libraries: based n PacketVide's OpenCORE; the libraries supprt playback and recrding f many ppular audi and vide frmats, as well as static image files, including MPEG4, H.264, MP3, AAC, AMR, JPG, and PNG Surface Manager: manages access t the display subsystem and seamlessly cmpsites 2D and 3D graphic layers frm multiple applicatins LibWebCre: a mdern web brwser engine which pwers bth the Andrid brwser and an embeddable web view SGL: the underlying 2D graphics engine 3D libraries: an implementatin based n OpenGL ES 1.0 APIs; the libraries use either hardware 3D acceleratin (where available) r the included, highly ptimized 3D sftware rasterizer FreeType: bitmap and vectr fnt rendering SQLite: a pwerful and lightweight relatinal database engine available t all applicatins Andrid Runtime Andrid includes a set f cre libraries that prvides mst f the functinality available in the cre libraries f the Java prgramming language. Every Andrid applicatin runs in its wn prcess, with its wn instance f the Dalvik virtual machine. Dalvik has been written s that a device can run multiple VMs efficiently. The Dalvik VM executes files in the Dalvik Executable (.dex) frmat which is ptimized fr minimal memry ftprint. The VM is register- based, and runs classes cmpiled by a Java language cmpiler that have been transfrmed int the.dex frmat by the included "dx" tl.

44 The Dalvik VM relies n the Linux kernel fr underlying functinality such as threading and lw- level memry management Linux Kernel Andrid relies n Linux versin 2.6 fr cre system services such as security, memry management, prcess management, netwrk stack, and driver mdel. The kernel als acts as an abstractin layer between the hardware and the rest f the sftware stack Other Features Andrid supprts a lt f useful functins, smetimes dependent n hardware capabilities, like the fllwing: Integrated brwser based n the pen surce WebKit engine Optimized graphics pwered by a custm 2D graphics library; 3D graphics based n the OpenGL ES 1.0 specificatin (hardware acceleratin ptinal) SQLite fr structured data strage Media supprt fr cmmn audi, vide, and still image frmats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF) GSM Telephny (hardware dependent) Bluetth, EDGE, 3G, and WiFi (hardware dependent) Camera, GPS, cmpass, and accelermeter (hardware dependent) Rich develpment envirnment including a device emulatr, tls fr debugging, memry and perfrmance prfiling, and a plug- in fr the Eclipse IDE Andrid Maps API Ggle Andrid includes Ggle Maps between his wn applicatins. But Andrid als allws creating persnalized Ggle Map in ther applicatins by the maps package. The maps package allws applicatins t display and cntrl a Ggle Map interface. T create a Ggle Map is necessary t extend MapActivity and implement a MapView in the layut. This is nt a standard package in the Andrid library. In rder t use it, we must add a specific XML element, as a child f the applicatin element, in AndridManifest.xml file. In rder t use a MapView in an applicatin, is needed t include the "andrid:apikey" attribute in the MapView (r include a key in the MapView cnstructr). 4.3 IP Multimedia Subsystem The fllwing paragraphs prvide an assessment f the mst imprtant Open Surce IMS platfrms, clients and API services. The analysis f all this sftware prvides an verview f what culd be useful fr the creatin f the IMS client fr PICO demnstratr and running n prtable devices. This part f the dcument is divided in fur parts: the first ne is an intrductin abut all existing free IMS clients, the secnd ne shws the mst imprtant free IMS platfrms, the third and furth

45 ne describe tw particular IMS client, the fifth ne describes a set f API that implements several IMS services and the last ne summarizes the cnclusins abut what culd be useful t ur prject IMS platfrms verview In this paragraph with the wrd platfrm represents a set f elements and tls that interacts with an IMS applicatin and supprts it. We analyzed the Open Surce IMS Cre that supprts several IMS clients (like UTC IMS client and IMS cmmunicatr), Mbicents platfrm and dubang framewrk. The Open IMS Cre, the first examined platfrm, is an implementatin f IMS Call Sessin Cntrl Functins (CSCFs) and a lightweight Hme Subscriber Server (HSS), which tgether frm the cre elements f all IMS/NGN architectures as specified tday within 3GPP, 3GPP2, ETSI TISPAN and the PacketCable initiative. The fur cmpnents are all based upn Open Surce sftware (e.g. the SIP Express Ruter (SER) r MySQL). This platfrm is nt created t prduct applicatins in a cmmercial cntext. Its sle purpse is t prvide an IMS cre reference implementatin fr IMS technlgy testing and IMS applicatin prttyping fr research purpses. The fllwing image shws an verview f the architecture. Figure 22: Open IMS Cre verview. The secnd platfrm cnsidered in ur analysis abut free IMS platfrms is Mbicents. It s a highly scalable event- driven applicatin server. Mbicents is the first and nly Open Surce VIP Platfrm

46 certified fr JSLEE 1.0 cmpliance. It cmplements J2EE t enable cnvergence f vice, vide, instant messaging and data in next generatin applicatins. In the scpe f telecm Next Generatin Intelligent Netwrks (NGIN), Mbicents fits in as a high- perfrmance cre engine fr Service Delivery Platfrms (SDP) and IP Multimedia Subsystem (IMS). Mbicents enables the cmpsitin f Service Building Blcks (SBB) such as call cntrl, billing, user prvisining, administratin, and presence sensitive features. The JAIN SLEE specificatin allws ppular prtcl stacks such as SIP t be plugged in as resurce adapters. The fllwing figure describes the Mbicents architecture. Figure 23: Mbicents slutin verview IMS clients Over the last years, with the emergent effrt n IMS Cre Netwrk develpment and NGN services, cmes the need t have an IMS Client able t use and test all the new services and cnvergence scenaris made pssible with SIP and the IMS architecture. Here we have identified sme IMS clients that can be a gd starting pint fr the cnstructin f the PICO client: The Mercur IMS client is freely available (clsed- surce) The UCT IMS client is available under the GPL (pen surce) The IMS Cmmunicatr is available under the GPL (pen surce)

47 Open IMS client is available nly cmmercially. Yet, there is als a free binary OpenIC_Lite versin available right here Mercur IMS Client is the mst cmplete IMS free client but it is clsed surce and the use f Mercur IMS Client as framewrk (C++, C# r VB.NET) t develp ther IMS services r clients is nly fr payment. The Open IMS Client (available nly cmmercially) is a framewrk that ffers a prgrammable interface fr develpment f varius IMS applicatins. The wrd "Open" means extendible and shuld nt be cnfused with "Open Surce". The Open IMS Client (Lite versin) is a free IMS based sft phne. Als in this case, the wrd "Open" means extendible and shuld nt be cnfused with "Open Surce". Based n the architecture f OpenIC, OpenIC Lite is designed t highlight sme f the rich features available with cmmercial IMS client. The use f the client that ffers a framewrk fr develpment f varius IMS applicatins is nt develped in Open IMS Client Lite. Fr these reasns we fcus ur attentin abut the tw GPL (pen surce client). Bth clients are based n Open IMS Cre UCT IMS Client Regarding IMS client technlgies, we reprt like first pen surce IMS client the UCT IMS Client. It is designed t wrk in cnjunctin with the Fraunhfer FOKUS Open IMS Cre. At present the client is still in active develpment and there are several knwn bugs. The client supprts a system fr authenticatin called AKA, and emulates IMS signaling as far as pssible. The current versin supprts vice and vide calls (numerus cdecs), pager- mde instant messaging, Presence, an IPTV viewer and an XCAP client. The fllwing list shws all the mdules f UCT IMS Client: Methds t handle bth SIP and IMS exsip events Methds t handle bth SIP and IMS interface events Methds t handle IMS exsip events Methds t handle IMS interface events Main Media Preferences Presence SDP bdy helpers Methds t handle SIP exsip events Methds t handle SIP interface events Sund cnverter Useful methds Watchers XCAP Every mdule culd cntain several methds. Fr example the mdule Methds t handle bth SIP and IMS interface events implements all the fllwing methds:

48 vid set_mde(): Sets the mde int either IMS r SIP mde, used nly n startup vid terminate_call(): Terminates a call, methd is the same fr SIP and IMS mde vid reject_call(): Rejects a call, methd is the same fr SIP and IMS mde vid cmmn_start_im_sessin(cnstgchar *chat_uri_entry): Starts an Instant Messaging sessin as a result f sending a MESSAGE Opens an IM Windw and brings crrect tab t the fregrund Methd is the same fr IMS and SIP mde. The parameter chat_uri_entry is URI t start the IM sessin with vid cmmn_send_dtmf(int val): Sends DTMF tnes in an NFO message. The parameter val is the value f the DTMF tne t send This client, written in C and based n exsip (a library that hides the cmplexity f using the SIP prtcl fr mutlimedia sessin establishement), requires a Debian OS r a Linux- based Operating System. Several related prjects have resulted frm the UCT IMS Client: UCT Advanced IPTV: This slutin invlves a SIP based Indirectin server that facilitates an RTSP sessin between the UCT IMS Client and any RTSP supprted media server. A 3rd Party RTSP supprted media server is required. UCT Plicy Cntrl Framewrk: The UCT Plicy Cntrl Framewrk incrprates Plicy and Charging Rule Functin (PCRF) and Plicy and Charging Enfrcement Functin (PCEF) functinality int the FOKUS Open Surce IMS Cre. XML Netwrk level cntrl plicies are defined - the PCRF cmbines these plicies with service infrmatin frm the service cntrl layer (e.g. P- CSCF) and creates plicy enfrcement rules t be enfrced in the transprt layer at the PCEF. UCT Back- t- back User Agent: The UCT Back- t- back agent is a simple server that sets up a call between tw registered IMS clients. When incrprated with a web- page the user agent can be used as a click- t- dial server. UCT IPtv Streaming Server: The UCT IPtv Streaming Server allws bradcast vide streaming ver an IMS netwrk. The prject is n lnger under active develpment, and users are directed t UCT Advanced IPTv fr a mre cmprehensive and standards cmpliant IPTv implementatin. Hwever the Streaming server is still peratinal and remains fr cmpatibility purpses. The first versin f this client, released in December 2006, was the The last versin, released in July 2008, is the All sftware is released under the GNU General Public License versin IMS Cmmunicatr Thrugh the evaluatin wrk we analyze, like secnd slutin, the IMS- Cmmunicatr. This prject is based n the ld versin f the SIP- Cmmunicatr sftphne. It is built n tp f the JAIN- SIP RI (a full implementatin f RFC 3261), in which cntributins were als made t supprt the IMS SIP extensins defined by 3GPP and IETF. The IMS- Cmmunicatr media stack is prvided by the Java Media Framewrk (JMF) API. Despite being written in Java and accmplishing multiplatfrm cmpliance, there are n plans fr prting IMS- Cmmunicatr t the J2ME CDC envirnment. The main develpment effrts made t extend SIP- Cmmunicatrs IMS- cnfrmance fcused in the IMS Registratin and Authenticatin, and the IMS Sessin Establishment. Fr the IMS Registratin and Authenticatin, the supprt f an IMPI (IP Multimedia Private Identity), the authenticatin

49 algrithm AKAv1 (with the MILENAGE 3GPP reference algrithm), the subscriptin t the reg event package and the Security Agreement mechanism were implemented. Regarding the IMS Sessin Establishment, the Precnditin Mechanism was implemented, as als added the supprt f Early Media and Call Transfer. The IMS- Cmmunicatr features als include a Setup wizard, Vice and Vide calls, Dial histry, Cntact list, IM and Presence supprt. The interperability with the Open IMS Cre is cnsidered an imprtant feature, s the IMS- Cmmunicatr prject will cntinue t supprt it, as it des since its release. IMS Registratin and Authenticatin supprt f IMPI authenticatin algrithm AKAv1 subscriptin t the reg event package Security Agreement mechanism (n IPSec thugh) IMS Sessin Establishment Precnditin Mechanism Early Media Call transfer Other IMS features: Setup wizard Vice and Vide calls Dial histry Cntact list Instant Messaging Presence supprt The IMS Cmmunicatr runs n Windws XP OS and n Linux OS. The develpment status f the prject is 4- Beta. IMS- Cmmunicatr is an pen- surce prject, licensed with the Apache Sftware License and the GNU Lesser General Public License (LGPL). 4.4 Selected PICO technlgies In the previus chapters several technlgies have been analyzed and discussed. Belw there is a brief descriptin f the final technlgies used in PICO PICO Server (PSCDS) PICO server is a JAVA EE applicatin. It uses PstgreSQL as database t cllect all infrmatin related t the PSCD Users and Emergencies fr a specific area. As Rule engine, PICO uses Drls frm JBOSS. It takes sme rules as input and prvides the best actin t d fr each user, fr example, a relevant applicatin in case f emergency r an audi/vide call t ther PSCD User etc.

50 As IMS framewrk (server side), PICO uses dubang which is a 3GPP IMS framewrk fr bth embedded and desktp system. It is written in ANSI- C and s is very pwerful. It expses a Java wrapper t allw cmmunicatin with the PICO JAVA EE applicatin PICO Client (PSCD) PICO client is the mbile applicatin. It is written in JAVA and cnverted by Dalvik machine fr Andrid system. As IMS framewrk (client side), PICO uses imsdrid which in turn is based n dubang as well. PICO extends its capabilities fr full applicatin supprt LST: A prtcl fr mapping Gegraphic lcatins t public safety answering pints PICO architecture can take advantage als using LST prtcl fr the answering pint management. LST has been designed t serve as a mapping prtcl fr handing PSAPs (Public Safety Answering Pints). It allws end systems and VIP prxies t map lcatin data int URLs representing either PSAPs r ther SIP prxies that perfrm a mre fine- grained mapping. LST is designed t perate glbally, with a highly- distributed authrity. Figure 245: Lst: Draft Architecture