Chapter 7
Conclusion and future work
7.1 Conclusion
The main goal of this project has been to implement a GSM call service for Mobile Arts. The product is supposed to be used for experimentation purposes which was reflected in the design and implementation. This enables further work as introduced in the following sections.
Erlang/OTP design principles helped to design a modular distributed system.
An agile process such as Scrum helped in planning efficiently and allowed the team to commit to work while the customer was assured of an high quality product.
The team and MA considers the project successful.
7.2.2 Call waiting and call deflection
Call Waiting can be used to park and/or redirect active calls. It also allows the user to receive a second call while in an active call. This is not currently supported, the signalling and virtual circuit-switching are designed to work with linear calls. However, since signalling is according to 3GPP specifications the signalling components in the MUS can be adapted according to the correspond-ing specifications by the 3GPP.
Call Waiting and Call Deflection are closely related to conference calls and have to be at least partly implemented to support conference calls. The conference call initiating MS must be able to park a running call to call or answer a call from a third party for a conference call.
7.2.3 GPRS/EDGE support
GSM call service does not support any data transmission. In light of the pop-ularity of data services this would be a useful addition. The OpenBSC-project has open source GPRS projects running [11], this work could be used to extend the call service with data transmissions.
7.2.4 3G support
According to [11], the OpenBSC project is planning to support 3G. As soon as OpenBSC supports 3G it would be feasible to integrate 3G support into our call service. The similar structure of 2G and 3G networks should allow this without changing too much of the call service’s architecture.
7.2.5 Multiple BTS/BSCs per MSC
To cover bigger areas and support more concurrent calls at the same time the call service could be extended to support multiple BSCs and/or multiple BTSs.
7.2.6 External ISUP interface
While more BSCs and/or BTSs can cover a wider area and more concurrent calls could an external ISUP interface make it possible to connect the call service to other GSM networks.
7.2.7 Media Gateway transcoding
Transcoding is closely related to several other future work items in this list.
It is needed to connect the call service to other types of network, to support different codecs on different hardware and to be able to manipulate voice traffic in the media gateway. This is needed for example when doing conference calls or in-call acoustical signals from the network.
7.2.8 MA HLR
The MA feature was originally planned to be in the call service, but the HLR functionality has only been stubbed. There exists an Erlang interface for the SS7 stack provided by Mobile Arts from last year, that according to our investigation during the project would be sufficient for call handling with a few small changes.
7.2.9 SMS support
Previous year’s project CS course product SMS service, was not integrated into this product. Doing that would improve the completeness of the GSM function-ality covered by the call service. The architecture of the SMS service has to be adapted to the new structure of the call service.
7.2.10 Tones
Inserting tones would be a necessary addition which could be used to send error tones or info tones depending on the cause/reason for sending tone. A tone could be generated and sent to the Mobile Station.
Bibliography
[1] 3GPP. GSM 04.08 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/
04_series/04.08/0408-700.zip, 1998. Mobile radio interface layer 3 specification.
[2] 3GPP. GSM 08.58 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/
08_series/08.58/0858-700.zip, 1998. Base Station Controller - Base Transceiver Station (BSC - BTS) interface; Layer 3 specification.
[3] 3GPP. GSM 23.002 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/
23_series/23.002/23002-700.zip, 2005. Technical Specification Group Services and Systems Aspects; Network architecture.
[4] 3GPP. GSM 23.018 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/
23_series/23.018/23018-700.zip, 2005. Technical Specification Group Core Network and Terminals; Basic call handling; Technical realization.
[5] 3GPP. GSM 24.008 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/
24_series/24.008/24008-700.zip, 2005. Technical Specification Group Core Network and Terminals; Mobile radio interface Layer 3 specification;
Core network protocols; Stage 3.
[6] 3GPP. GSM 29.002 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/
29_series/29.002/29002-700.zip, 2005. Technical Specification Group Core Network and Terminals; Mobile Application Part (MAP) specifica-tion.
[7] 3GPP. GSM 48.008 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/
48_series/48.008/48008-700.zip, 2005. Technical Specification Group GSM/EDGE Radio Access Network; Mobile Switching Centre - Base Sta-tion System (MSC-BSS) interface; Layer 3 specificaSta-tion.
[8] 3GPP. GSM 48.008 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/
48_series/48.008/48008-700.zip, 2005. Technical Specification Group GSM/EDGE Radio Access Network; Mobile Switching Centre - Base Sta-tion System(MSC-BSS) interface; Layer 3 specificaSta-tion.
[9] 3GPP. GSM 23.012 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/
23_series/23.003/23003-700.zip, 2006. Technical Specification Group Core Network and Terminals; Location management procedures.
[10] 3GPP. GSM 48.006 v.7.0.0. http://www.3gpp.org/ftp/Specs/archive/
48_series/48.006/48006-700.zip, 2006. Technical Specification Group GSM EDGE Radio Access Network; Signalling transport mechanism spec-ification for the Base Station System - Mobile-services Switching Centre (BSS - MSC) interface.
[11] Harold Welte. Free Software GSM Protocol Stacks OpenBSC, OpenS-GSN, OpenGOpenS-GSN, OsmocomBB. http://elinux.org/images/6/65/
Elce2010-welte-openbsc.pdf, 2010.
[12] Henrik Back and Ming Zhao. Voice Mail System for IP Multimedia Sub-system. Master’s thesis, Uppsala University, 2008.
[13] Henrik Kniberg. Scrum and XP from the Trenches. InfoQ, 2007.
[14] ITU-T. Q.764. http://www.itu.int/rec/T-REC-Q.764-199912-I, 1999.
Signalling connection control part formats and codes.
[15] ITU-T. Q.713. http://www.itu.int/rec/T-REC-Q.713-200103-I, 2001.
Signalling connection control part formats and codes.
[16] ITU-T. H.248.1. http://www.itu.int/rec/T-REC-H.248.1-200509-I, 2005. Gateway control protocol: Version 3.
[17] ITU-T. H.248.8. http://www.itu.int/rec/T-REC-H.248.8-200708-I, 2007. Gateway control protocol: Error code and service change reason description.
[18] Ken Schwaber and Jeff Sutherland. Scrum Guide. http://www.scrum.
org/storage/scrumguides/Scrum_Guide.pdf, 1991-2011.
[19] nanoBTS. The world’s most deployed picocell. http://www.hexazona.
com/nexwave/docs/ipaccess/nanoGSM%20Brochure.pdf, 2012.
[20] Network Working Group. RTP: A Transport Protocol for Real-Time Ap-plications. http://www.ietf.org/rfc/rfc3550.txt, 2003. RFC 3550.
[21] Olle Gällmo. Projekt DV (Project CS) 2010. http://www.it.uu.se/edu/
course/homepage/projektDV/ht10, 2010.
[22] Team Mobile Arts Project CS 2011. Course report GSM Call Service, 2012.
[23] The Osmocom Project. Osmocom SS7 codec git repository. http://cgit.
osmocom.org/cgit/erlang/osmo_ss7/, 2011.
[24] The Osmocom project. nanoBTS. http://openbsc.osmocom.org/trac/
wiki/nanoBTS, 2012.
Chapter 8
Appendix A: Installation instructions
8.1 Hardware
• One ip.access nanoBTS GSM 1800 (v.139 rev.31)
• At least one x86_64 compatible computer