Conclusiones

Conclusiones “En las adversidades sale a la luz la virtud” Aristóteles.

Capítulo V.- Conclusiones 1.- Conclusiones    

Están claras las ventajas de IMS para una operadora, pero hay que  hacerlo  atractivo  para  el  cliente,  de  forma  que  así  se  justifique  la  integración  de  este  subsistema  en  la  arquitectura  de  la  red  de  una  operadora  de 3G. La diferencia entre una operadora y un  usuario  o  cliente  es  la  concepción  de  la  tecnología,  la  operadora  lo  ve  en  términos de protocolos y tecnología en sí, mientras que los usuarios  son compradores de servicios.     Por  tanto,  la  forma  de  “vender”  IMS  es  diseñar  atractivos  servicios  como el que se presenta en este proyecto. Se trata, pues, de un éxito  hipotecado al dinamismo y facilidad de manejo de las herramientas  de desarrollo de servicios para IMS.     El plugin que se ha manejado para este servicio, lejos de ser dinámico  y  eficiente,  ha  resultado  en  ocasiones  tedioso,  rudimentario  e  ineficiente. Cabe destacar que el framework de pruebas es poco ágil  ya que no permite hacer un seguimiento detallado de las pruebas ni  detenerlas cuando convenga; cuando la prueba va adquiriendo peso  puede  llegar  a  ser  un  inconveniente  funcional  importante.  Es  digna  de  mención  la  considerable  limitación  de  sólo  poder  arrancar  un  cliente por equipo, o a lo sumo dos, pero un cliente java y otro en el  emulador  proporcionado  con  la  herramienta.  Además  dicho 

97

Conclusiones

Conclusiones

emulador  requiere  un  trabajo  adicional  para  conseguir  un  mayor  parecido  al  comportamiento  del  terminal  físico  real  ya  que  en  algunas ocasiones puede suponer una carga adicional de trabajo; por  otra  parte,  hay  que  pararse  a  configurar  estáticamente  la  ip  del  emulador  debido  a  que  no  consigue  obtenerla  por  DHCP  aunque  aparentemente está capacitado para ello. Por último, añadir, que algo  que  adquiere  tanta  importancia  en  la  integración  de  los  servicios  como son las “mapping rules”, ofrecen una interfaz de definición que  resulta engorrosa e ineficiente.    Por otra parte, las API’s en que se basa la implementación del cliente  no están al nivel de desarrollo necesario para el diseño de un servicio  de  cierta  envergadura.  De  hecho,  no  todos  los  métodos  SIP  están  completamente  soportados  ya  que  en  algunos  no  se  pueden  incluir  ciertas  cabeceras.  Está  más  orientada  a  la  recepción  que  al  envío  de  métodos.    Por  todos  los  contratiempos  anteriormente  enunciados  y  la  escueta  documentación  disponible  hemos  tenido  que  acudir  al  soporte  presencial de Ericsson en el laboratorio Minerva y al foro de Ericsson  para  desarrolladores  de  servicios  para  IMS  en  SDS  (  http://www.ericsson.com/mobilityworld/sub/open/technologies/ims_ poc/forum_topics.html?FID=164&Start=1&Step=25 ). A la mayoría de  las  consultas  hemos  obtenido  orientaciones  más  que  respuestas  definitivas,  pero  siempre  hemos  conseguido  resolver  lo  planteado.  Otra de las consecuencias de las limitaciones de la herramienta y de  la API ha sido tener que prescindir de una de las funcionalidades del  servicio  contempladas  en  la  fase  de  diseño,  Push  To  Talk  (PTT),  ya  que  no  ofrecían  todo  el  soporte  necesario  para  abordar  la  implementación de dicha funcionalidad.    Hemos  apostado  por  un  método  de  trabajo  basado  en  la  máxima  “cuatro  ojos  ven  más  que  dos”  que  nos  ha  llevado  a  desarrollar  habilidades  de  toma  de  decisiones  desde  distintos  enfoques  y  buscando  puntos  de  encuentro.  Esto  nos  ha  permitido  compensar  una de las carencias formativas de la carrera que sin embargo están  muy demandadas en el tejido empresarial actual.     

98

Conclusiones

Líneas futuras

2.- Líneas futuras     Una  de  las  posibles  líneas  de  trabajo  que  se  podrían  abordar  en  un  futuro está orientada al análisis y monitorización del tráfico cursado  por  el  servicio.  El  plugin  actual  genera  un  archivo  de  trazas  con  todos  los  mensajes  intercambiados  entre  CSCF  y  SIP‐AS.  Podría  ser  interesante  implementar  un  filtro  que  capturase  la  información  de  interés  de  esas trazas y las dibujara en un  diagrama de intercambio  de mensajes.    En  cuanto  a  las  comunicaciones  se  podrían  abordar  dos  líneas  de  trabajo  encaminadas  a  enriquecer  las  posibilidades  del  servicio.  Por  un lado, dotarlo de la funcionalidad PTT tal como se comentaba en  la  descripción  del  servicio  pero  que  debido  a  limitaciones  de  la  plataforma  no  se  ha  podido  abordar.  Por  otra  parte,  en  algunos  escenarios, podría ser de interés que las comunicaciones fueran de 1  a N, es decir, todos se comunican con el creador pero no entre ellos, y  el creador con todos.    Para el seguimiento del servicio por parte de la operadora se podría  plantear el desarrollo de un software de monitorización de grupos y  usuarios  orientado  a  obtener  estadísticas  de  uso  en  tiempo  real  que  permitan tomar decisiones que optimicen la configuración de la red  para la explotación del servicio.    Por  último,  habría  que  acometer  el  siguiente  paso  en  el  ciclo  de  desarrollo de un servicio, su prueba en maqueta antes de desplegarlo  en el escenario real. Habría que negociar con alguna operadora para  trasladar  el  servidor  del  SIP  Container  del  SDS  a  un  SIP  AS  real  de  una arquitectura IMS completa.     

99

Conclusiones

Glosario

3.- Glosario     3GPP  AS  ATF  B2BUA  BSS  BTS  CAMEL  CAP  CN  CPoCS  CSCF  DA  DCU  DNS  FB  GC  GGSN  GMSC  GPRS  GSM  gsmCSF  GTT  GW  HLR  HSS  I‐CSCF  IFC  IM  IMS  IM‐SSF  IP  LBS  MAA  MAR  MGCF  MGW  MMS  MRF  MRFC 

3rd Generation Partnership Project  Application Server  Automated Testing Framework  Back to Back User Agent  Base Station Subsystem  Base Transceiver Station  Customized Applications for Mobile network Enhanced Logic  CAMEL Application Part  Core Network  Controlling PoC Server  Call Session Control Function  Diagrama de Actividades  Diagrama de Casos de Uso  Domain Name System  Fuera de banda  Group Creator  Gateway GPRS Support Node  Gateway Mobile Switching Centre  General Packet Radio Services  Global System Mobile  GSM Service Control Function  Global Text Telephony  Gateway  Home Location Register  Home Subscriber Server  Interrogating ‐ Call Session Control Function  Initial Filter Criteria  Instant message  IP Multimedia Subsystem  IP Multimedia Service Switching Function  Internet Protocol  Location Based Services  Multimedia Auth Answer  Multimedia Auth Request  Media Gateway Controller Function  Media Gateway  Multimedia Messaging System  Multimedia Resource Function  Media Resources Function Controllers  100

Conclusiones

MRFP  MS  MSC  OP  OSA  P‐CSCF  PDF  PoC  PoCT  PPoCS  PSTN  PTT  QoS  RTC  SCS  S‐CSCF  SDP  SDS  SGSN  SGW  SIMPLE  SIP  SLF  SMS  SMSC  SSF  UA  UAA  UAR  UDB  UML  UMTS  URI  USSD  VLR  WAP  XCAP   

Glosario

Media Resources Function Processors  Mobile Station  Mobile Switching Center  Operadora  Open Service Access  Proxy ‐ Call Session Control Function  Policy Decision Function  PTT Over Celular  PoC Terminal  Participating PoC Server  Public Switched Telephony Network  Push To Talk  Quality of Service  Red Telefónica Conmutada  Service Capability Server  Serving ‐ Call Session Control Function  Session Description Protocol  Service Development Studio  Serving GPRS Support Node  Signalling Gateway  SIP for Instant Messaging and Presence Leveraging Extensions  Session Initiation Protocol  Subscriber Location Function  Short Message Service  Short Message Service Center  Service Switching Function  User Agent  User Authorization Answer  User Authorization Request  User Data Base  Unified Modeling Language  Universal Mobile Telecommunications System  Uniform Resource Identifier  Unstructured Supplementary Service Data  Visit Location Register  Wireless Application Protocol  XML Configuration Access Protocol 

101

Conclusiones

Glosario

   

102