Cloud-Based Alerting System
for IP-Telephony
A prototype development
PER-JOHAN SIMON JAKOBSSON
K T H R O Y A L I N S T I T U T E O F T E C H N O L O G Y
I N F O R M A T I O N A N D C O M M U N I C A T I O N T E C H N O L O G Y
DEGREE PROJECT IN COMMUNICATION SYSTEMS, SECOND LEVEL STOCKHOLM, SWEDEN 2015
Cloud-Based Alerting System for
IP-Telephony
A prototype development
Per-Johan Simon Jakobsson
2015-07-19
Master’s Thesis
Examiner and Academic adviser
Gerald Q. Maguire Jr.
Industrial adviser
Christer Ulfsparre
KTH Royal Institute of Technology
School of Information and Communication Technology (ICT) Department of Communication Systems
Abstract | i
Abstract
An increasing number of people in Sweden are having problems with their hearing ability. The three major tools to aid hearing-impaired and deaf individuals are: hearing aids, special telephony, and alerting systems. Both hearing aids and telephony have seen a huge technical development. Hearing aids have gone from huge ponderous devices to small delicate in-ear devices. Simple text telephones have evolved into total conversation telephones with audio, video, and text all operating in real-time. Although smart lamps and other alerting services not specifically made for hearing-impaired individuals do exist, the development of alerting system is unsatisfactory. The gap in technology is a huge problem and integration between modern products and alerting systems is getting harder. This thesis explores how to close this gap. The result of this thesis project is a prototype that provides the missing technological link between an alerting systems and modern smart devices. An eventual product should support all kinds of services, but the prototype is limited to solving the problem of connecting an alerting system to a modern total conversation telephones. The prototype was evaluated and based on the evaluation data a timeline was created. An overall positive response towards the product exists and the timeline had adding more third party services (such as Skype and FaceTime) as a high priority. The complete timeline as well as adding Signal Initiation Protocol support is left as future work.
Keywords
Sammanfattning | iii
Sammanfattning
I Sverige har antalet personer med hörselskada ökat de senaste åren. För att hjälpa de med hörselproblem finns det tre viktiga hjälpmedel: hörapparater, special telefoner och varseblivningssystem. Stora teknologiska framsteg har skett för både hörapparater och special telefoner. Hörapparater har gått från stora otympliga apparater till små nätta anordningar som man har i örat. Enkla texttelefoner är idag komplexa system som stödjer både video, ljud och text i realtid. Även fast smarta lampor och andra varseblivningsprodukter existerar så är utveckling för varseblivning speciellt gjorda hörselskadade och döva undermåliga. Gapet som skapats mellan moderna varseblivningsprodukter och varseblivning som hjälpmedel växer sig allt större. Denna rapport ska undersöka detta gap. Resultatet av detta projekt är en prototyp som tillhandahåller den teknologin som ska länka modern varseblivning och varseblivning som hjälpmedel. Den tänkta produkten kan användas för många olika tjänster men i detta projekt är den begränsad till total konversations telefoner. Prototypen har blivit utvärderad och en tidslinje, baserad på utvädringen, har skapats. Tidslinjen ska beskriva kommande tjänster och enheter som skall kunna användas tillsammans med prototypen. Det visar sig att den skapade prototypen blev positivt mottagen och att tjänster som Skype och Facetime skulle ha hög prioritering på tidslinjen.
Nyckelord
Acknowledgments | v
Acknowledgments
I would like to thank my whole family for supporting me through the years of study. Special thanks go to my mother (Reené Jakobsson) and my father (Per-Martin Jakobsson) and my siblings (Jakob, Adam, and Jossefin Jakobsson) as they helped me through the years. I also want to show gratitude towards Pierré Eriksson, Bengt Åkerblom, Karina Eriksson and Nanna Vollen for their support through my life in Stockholm.
I also want to thank my examiner and supervisor (Professor Gerlad Q.MaguireJr.) who guided my through the writing of the report and came with constructive feedback and tips on what to do next and how to improve my thesis. His insight and opinions have been very helpful throughout the project.
Lastly, I want to thank Omnitor AB for giving me the opportunity to work with them for this project. Specially Christoffer Fridbreg and Christer Ulfsparre which took their time to help me out , discuses ideas, and guide the project.
Stockholm, July 2015 Per-Johan Simon Jakobsson
Table of contents | vii
Table of contents
Abstract ... i
Keywords ... i
Sammanfattning ... iii
Nyckelord ... iii
Acknowledgments ... v
Table of contents ... vii
List of Figures ... ix
List of Tables ... xi
List of acronyms and abbreviations ... xiii
1
Introduction ... 1
1.1
Background ... 1
1.2
Problem definition ... 2
1.3
Purpose ... 2
1.4
Goals ... 3
1.5
Research Methodology ... 4
1.6
Delimitations ... 4
1.7
Structure of the thesis ... 5
2
Background ... 7
2.1
Technological gap ... 7
2.1.1
Current Alerting Systems Technologies ... 7
2.1.2
Omnitor AB´s new solution ... 9
2.2
Related Work ... 10
2.2.1
Home Automation ... 10
2.2.2
Cloud-Based Services ... 11
2.2.3
Single-user Profiles for Alerting Systems ... 12
2.3
Other related work ... 12
2.3.1
Remote Residential Control System ... 13
2.3.2
Service in the Cloud ... 13
2.3.3
SIP as Service Provider ... 13
2.4
Summary ... 13
3
Methodology ... 15
3.1
Research Process ... 15
3.2
Data Collection ... 17
3.2.1
Sampling ... 17
3.2.2
Target Population ... 17
3.3
Experimental design/Planned Measurements ... 18
3.4
Assessing reliability and validity of the data collected ... 19
3.4.1
Reliability ... 19
3.4.2
Validity ... 19
viii| Table of contents
4
Realizing a cloud-based alerting system ... 21
4.1
Network Architecture Decision ... 21
4.1.1
Local Architecture ... 21
4.1.2
Direct Connection Architecture ... 22
4.1.3
Cloud-Based Architecture ... 23
4.1.4
Cloud-Connected Architecture ... 23
4.1.5
Summary ... 24
4.2
Platform Decisions ... 25
4.2.1
Alerting System Controller Hardware ... 25
4.2.2
Alerting System Controller Cloud ... 27
4.2.3
Protocol and Message Format ... 29
4.3
Assembling the Prototype ... 30
4.4
Software Development ... 33
4.5
Protocol Messages ... 36
5
Analysis ... 39
5.1
Major results ... 39
5.1.1
Current Solution ... 40
5.1.2
Potential Future Solutions ... 42
5.1.3
Other ... 44
5.2
Future Timeline ... 45
5.3
Reliability Analysis ... 46
5.4
Validity Analysis ... 47
5.5
Discussion ... 47
6
Conclusions and Future work ... 49
6.1
Conclusions ... 49
6.2
Limitations ... 50
6.3
Future work ... 50
6.4
Reflections ... 50
References ... 53
Appendix A: User survey ... 57
List of Figures | ix
List of Figures
Figure 2-1:
Home Automation Setup. (Inspired by Figure 1 on page 11
of [40]) ...11
Figure 3-1:
The Research Process and its different phases and a small
explanation ... 15
Figure 3-2:
Research strategy of action research ... 18
Figure 3-3:
The Software development life cycle. (Inspired by Figure 1
on page 2 of [47]) ... 18
Figure 4-1:
Local architecture. ... 22
Figure 4-2:
Direct connected architecture. ... 22
Figure 4-3:
Cloud-based architecture. ... 23
Figure 4-4:
The cloud-connected architecture. ... 24
Figure 4-5:
Shows the different amazon services and their relationship
to each other. ... 28
Figure 4-6:
An example of how SIP could be used when sending
messages between ASC-Server and ASC-Device. This figure
was inspired by Message F1 (figure 1) in [65] ... 30
Figure 4-7:
Shows the ASC-Device prototype as seen from the front. ... 31
Figure 4-8:
The ASC-Device prototype as it from the behind ... 32
Figure 4-9:
Inside ASC-Device prototype as seen from above ... 33
Figure 4-10:
A basic flow-chart of the two main programs in the
ASC-System: the server and client software. The client is on the
left, while the server software is on the right. ... 35
Figure 4-11:
The JSON structure of an open channel message. The
messages are exchanged between third parties and the
ASC-Server. The full structure is required for every message... 36
Figure 4-22:
The message that can be sent through the closed channel.
Messages goes between ASC-Device and ASC-Server. Only
parts of the structure is required for a full message. ... 37
Figure 5-1:
Test users rating of the prototype as a product. One is bad
and ten is good. The mean value is 6.86 and the median is
7.0. ... 40
Figure 5-2:
The collected result that the tests users felt were important
in the current solution, the solution that they got to see and
tested. ... 42
Figure 5-3:
The collected result of what the tests users liked about the
future solution. This figure corresponds to question 4 about
new services that can be added. ... 43
Figure 5-4:
The collected result of what the tests users liked about the
future solution. This figure corresponds to question 5 about
new devices that can be added. ...44
Figure 5-5:
The timeline for future releases of features based on user
input. The two colors green and blue is used to differ
between services and devices, green is services and blue is
devices. ...46
List of Tables | xi
List of Tables
Table 2-1:
Different companies and one of their newest products and
which technology it uses. Note that a question mark is used
when the frequency is unknown. ... 8
Table 2-2:
Advantages and disadvantages of different devices and their
technologies. ... 14
Table 2-3:
Advantages and disadvantages of the implementation of
home automation system. ... 14
Table 3-1:
Duration for each of the four phases ... 17
Table 4-1:
Advantages and Disadvantages of the different
architectures. ... 25
Table 4-2:
Advantages and Disadvantages of different hardware
platforms for the ASC device. ... 27
Table 5-1:
Mapping of the rating comments into categories. The left
column is the category, while the right column shows how
many times this type of response was given (mapped). ... 41
Table 5-2:
Mapping of the future solution´s part II into categories.
The left column is category the right column is how many
times if was mapped ... 43
Table 5-3:
Lists the goals on how each goal was fulfilled. ... 47
List of acronyms and abbreviations | xiii
List of acronyms and abbreviations
3G Third generation
4G Fourth generation
AB Stock Company
API Application Programming Interface
ASC Alerting System Controller
ASC-Cloud Alerting System Controller Cloud
ASC-Admin Alerting System Controller Administration ASC-Device Alerting System Controller Device
ASC-Server Alerting System Controller Server
AWS Amazon Web Services
CI Cochlear Implants
CPE Customer-premises equipment
DIP Dual in-line package
DTLS Datagram Transport Layer Security
EC2 Elastic Cloud Computing
FM-radio Frequency Modulation Radio
GPDL Graphical Profile Definitions Language
GPIO general purpose I/O/
GSM Global System for Mobile
HDMI High-Definition Multimedia Interface
HRF Swedish National Association for Hearing-impaired
I/O Input/Output
IoT Internet of Things
IP Internet Protocol
IPsec Internet Protocol Security IPv6 Internet Protocol Version 6
IT Information Technology
ITU International Telecommunication Union JSON JavaScript Object Notation
MD5 Message-Digest
MiniPC Mini Personal Computer MySQL My Structured Query Language
NAT Network Address Translation
PC Personal Computer
PIC-micro Peripheral Interface Controller micro
RDS Relational Database Service
RF Radio Frequency
RJ-45 Registered Jack
S3 Simple Storage Service
xiv| List of acronyms and abbreviations
SEK Swedish Krona
SIP Signal Initiation Protocol
SIP-Server Signal Initiation Protocol - Server SK2-SS Sidekick II Strobe Light
SQL Structured Query Language
SRTP Secure Real-time Transport Protocol
SSL/TLS Secure Socket Layer / Transport Layer Security TC-device Total Conversation Device
TCP Transmission Control Protocol
TTY Telecommunications Device for the Deaf
USB Universal Serial Bus
USB-alert Universal Serial Bus - alert
VPC Virtual Private Cloud
VoIP Voice over Internet Protocol Wi-Fi Wireless Fidelity
Introduction | 1
1 Introduction
This chapter describes the specific problem that this thesis addresses, the context of the problem, and the goals of this thesis project. Section 1.5 describes the research methodology used in this thesis, while Section 1.6 delimits the scope of this thesis project. The chapter concludes with an outline of the structure of the thesis.
When a machine wants to signal its user it can show information on a display, play a ring tone or play a tune, or in some other way contact the user through their human senses. An alerting system is a system designed to notify its user. Human interaction software today frequently implements an alerting system. When mentioning alerting systems most people think of only tools for aiding hearing/seeing impaired people perceive information that others perceive easily. However, alerting systems are actually far more general (see for example [1]).
Today alerting systems are advanced and integrated with the Internet and often communicate via smart-phones and tablets [2]–[4]. Alerting systems created for hearing-impaired and deaf individuals usually use radio and line carrier communication, rather than being Internet based system [5]–[10]. This thesis project explores the technological gap between current alerting systems and the out-of-date alerting systems made for hearing-impaired and deaf people.
The project began with a background study of alerting systems and ended with the development and evaluation of a prototype alerting systems that takes advantage of the Internet. This prototype is an alerting system that combines a client and a cloud-based server. Potential users of the prototype are the current customers of Omnitor AB [11], these are people with hearing problems. The prototype should bridge old and new technologies pushing the development for new alerting systems.
1.1 Background
An alerting system is a system that takes an input and then decides how to alert the user. One example is a coffee machine that indicates when coffee is ready by emitting a sound, sending an e-mail message, or flashing a light to signal to the user. Would I rather have my coffee maker call my cell phone than make a beep sound when my coffee is ready? This may lead to my selecting one product rather than another or perhaps configuring the product according to my preference. One group of people that more or less depending on an alerting system to live a normal life are those individuals that are either deaf or hearing-impaired, but the development of these systems are lagging behind what is technically and economically possible.
Today there exist 1.4 million people in Sweden with a hearing disability that affect their ability to perceive what others are saying [12]. Some of these people were born with hearing problem or even deafness, but it is much more common for these problems to develop over time. More than half of people facing this problem are between 16-64 (54%) years old and the rest 65-110 (46%) [12]. For a person with hearing disabilities or hearing loss it is crucial to have tools to aid them.
Special Telephones, hearing aids, and alerting Systems are some of the most common tools for people with hearing problems. Both special telephones and hearing aids have had a rapid technological growth during the last 50 years. Telephones for deaf and hearing-impaired have gone from simple text-telephones too much more advanced total conversation* devices (TC-device) which support real time video, speech, and text. The development of hearing aids has gone from simple electronic devices to implants inside the ear, for a complete list of the advancement of hearing aids see [13]. Total Conversation is a concept promoted by the International Telecom Union (ITU). Total
2 | Introduction
Conversation concerns the usage of telephones for people with disability. Apart from sending audio and video, it is also important that the text is sent one character at the time with the same intervals as its typed (also known as “timed text”) [14].
However, the one technology that has not improved very much is alarm and alerting systems made for hearing-impaired and deaf people [15]. A simple alerting system for hearing-impaired and deaf people consists of a sender, for example a doorbell-button, and a receiver, the doorbell; but instead of playing a tune the receiver flashes a light or vibrates to inform the deaf user that someone has pressed the doorbell button. There are many products offered by companies that offer a variety of services, the most common ones are alarm clocks, baby-monitors, doorbells, and motion sensors [16]. After looking at these products, it is notable that many companies utilize wireless technology for the communication between the sender and receiver as a replacement for their previous wired solutions. The wireless technologies used are various custom 2.4 GHz solutions or 868.3 MHz / 433 MHz solutions, the latter being the same technology used in older garage door openers [5]–[10], [17].
Although the development of alerting systems specifically made for hearing-impaired and deaf people has been slow, other types of alerting systems have been rapidly developed. The Internet of Things (IoT) is a new concept where everyday objects (“things”) have a connection to an infrastructure (the Internet) enabling communication between them. Several IoT products offer some alerting-features. These systems communicate over IP via Wi-Fi, Ethernet, Bluetooth, and wide area cellular systems (GSM, 3G, or 4G). Utilizing the Internet enables several features that were impossible in earlier simple alerting systems.
IoT is a fuzzy term and often described in different manners depending on which entity has defined it. In the European Research Cluster on the Internet of Things report “Internet of Things Strategic Research Roadmap from 2011” the following description is given:
“Internet of Things (IoT) is an integrated part of Future Internet including existing and evolving Internet and network developments and could be conceptually defined as a dynamic global network infrastructure with self configuring capabilities based on standard and interoperable communication protocols where physical and virtual “things” have identities, physical attributes, and virtual personalities, use intelligent interfaces, and are seamlessly integrated into the information network.” [18]
1.2 Problem definition
Current alerting systems created for deaf and hearing-impaired people are underdeveloped and use old technology compared to the rapid growth of regular consumer alerting systems. There is a need for an alerting system that can both handle the older technology and modern IP based technology. This project will investigate the usage, development, and evaluation of such a system in order to answer the question:
Is it possible to develop a general cloud-based alerting system which is compatible with current alerting systems and that can evolve to and exploit newer IP-based systems? If so, how would such a system be realized?
1.3 Purpose
This thesis discusses the needs of impaired persons, current alerting systems for hearing-impaired persons, development of the Internet of Things, and possible solutions to fill the gap between current alerting systems and the Internet of Things. Finally, the thesis presents the design, implementation, and evaluation of a prototype that offers a solution to the problem described in the
Introduction | 3
previous section. The target group for this thesis is individuals interested in software development, networking, and alerting system for a specific group of people, in this case specifically deaf and hearing-impaired people.
1.4 Goals
The goal of this project is to create a prototype of a system for alerting hearing-impaired and deaf people. This system should be able to be remotely triggered. This high-level goal is split into several sub-goals:
• Perform a market investigation of current alerting system specialized for hearing-impaired or deaf individuals both in Sweden and internationally.
• Design an alerting system that uses a cloud-based architecture.
• Propose different system solutions that fulfill both Omnitor ABs and user’s system requirements.
• Develop a prototype based on the most appropriate solution. • Evaluate the prototype.
• Document and present the work.
The deliverables for the company are a part of reaching the overall goal and include: • A working prototype meeting the minimal requirements and
• Documentation of the system to enable further development.
The benefits provided by this project are direct improvements in alerting system for hearing-impaired and deaf individuals and indirect improvements based upon educating other developers as to how they can exploit IoT, cloud, and networking technology in their development of alerting systems. The users of the final products will experience several benefits. Some of these benefits are increased choice of products from the market (the system can be used together with different brands of alerting devices), use their choice of alerting system with popular software (such as Skype), and remote support (where a support technician or service can connect directly to the device to carry out remote diagnostics and repair). The final product should work with any TC-telephone. For this project, the prototype is limited to working with Omnitor´s TC-solutions and products of common alerting system brands.
An ethical issue that occurs in this degree project is the usual ethical problem that exists when developing software. The user’s data needs to be handled in such a way that no personal information is leaked, i.e., to preserve the user’s data integrity. Additionally, intellectual property has to be respected; no source code should be used without the owner’s permission. Use of encryption has to be done in a manner that follows the laws of the country where the device is to be used. [19]
Sustainability is an important factor in software development. However, this factor is usually overlooked in actual development efforts. In order to be able to deliver software that is more economical and environmentally friendly different aspects of sustainability have to be considering throughout the software’s lifecycle [20]. While the degree project mainly focuses on the development process, notes about maintenance, production, and usage aspects have been added where appropriate.
4 | Introduction
1.5 Research Methodology
An in depth description of the research methodologies and methods are presented in Chapter 3, while the philosophical assumptions, research methods, and research approach will be presented here.
The philosophical assumptions concern the basis of the researcher’s view of what is acceptable knowledge and what is reality. Philosophical assumption comes in three different main flavors: positivism, realism, and interpretivism. Positivism assumes that understanding reality can be achieved by applying natural science to all fields. Realism is a similar to positivism in that sense that it also assumes that the reality can be understood through natural science methods, but realism assumes that natural science can be used to figure out an explanation - rather than natural science directly giving an explanation. The interpretive assumption is that reality is created by detailed observation of people in natural settings; it is the complete opposite of positivism. [21] For this thesis project, I have chosen an interpretive assumption as the best match for this project, as reality is not based on a traditional scientific method, but rather has a qualitative aspect.
After making our philosophical assumptions, the choice of research method defines how the researcher will carry out the research. Popular research methods include experimental, non-experimental, descriptive, analytical, fundamental, applied, conceptual, and empirical research [22]. For this thesis project, I have chosen to use the applied research method, because the background study done focuses on the development of a particular application, specifically to create a prototype of a potential future product.
The next step is to decide upon a research approach, which covers how conclusions are drawn and how to establish if they are valid or not. The most common research approaches are inductive and deductive. The inductive approach starts from a specific situation and then forms general ideas and conclusions as the research goes on. Deductive is the other way around, starting by collecting general ideas to get to a specific situation. [22] For this thesis project, I have chosen the deductive research approach because the project explores different technologies until we reach a system design that perfectly fits the requirements from Omnitor AB.
There are two basic categories of research methods: quantitative or qualitative. A quantitative research method is used when dealing with numbers, data, and measurements such as scale, range, and frequency. Qualitative on the other hand involves examining, reflecting, dealing with feelings and opinions, and development. [23] I have chosen a qualitative research method as we are dealing with the user interpretation and experience of the system. Also a qualitative research method is frequently used when developing a new system [22], which is exactly what this project attempts to do.
1.6 Delimitations
The market analysis carried out in the background study is far from a complete picture of all products on the market and companies offering products in this market. The companies included in this analysis are either listed on the “Assistech portal for assistive technology” [16] or companies for which Omnitor AB is a retailer. For the Internet of Things (IoT) products, a list on Postscape [24] was used.
During the development of the prototype, the technology chosen reflects the knowledge and experience of both Omnitor AB and the author of this thesis. This does not mean that different architectures, hardware, and software were not considered, but rather that the technology alternatives considered were not exhaustive.
Introduction | 5
The prototype developed during this degree project is simply a proof of concept prototype. A proof of concept prototype is the simplest version of a potential future product, and it is missing both the industrial design and many of the features that would be found in actual products [25]. The prototype is not expected to be aesthetically pleasing, but should provide most of the basic functionality necessary to show the importance and usage of the system.
1.7 Structure of the thesis
Chapter 2 presents the relevant background, going deeper into the current situations of the tools used by hearing-impaired and deaf individuals. The background continues into a brief look into the current alerting system market, Omnitor ABs role, and finishes up with earlier work that is related to this project. Chapter 3 goes into the research methodologies, explaining how the project will be carried out, both on scientific and practical level. The chapter will give a detailed explanation on how data is going to be collected and evaluated. Chapter 4 states the steps taken in order to realize this project, design choices and implementation steps are explained in detail. The chapter also presents how the prototype was created. Chapter 5 gives an explanation on how the prototype was evaluated and presents the data. The data is analyzed and a conclusion is extracted from the result. The last chapter 6 gives a conclusion on this project and thesis, going into a deeper view of the result, and through limitation and what the next logical steps for continuing work on the project.
Background | 7
2 Background
This chapter provides basic background information about current alerting systems and their market. Additionally, this chapter describes the company Omntior AB and its need for the product and the new product’s requirement(s). The chapter also describes related work with home automation and cloud-based services.
2.1 Technological gap
The need for tools to aid hearing-impaired and deaf people has increased during the last few years as the number of people with hearing problems has increased. In Sweden the percentage of hearing-impaired people has gone from 11.3% of the population in 1987, to 14.3% of the population in 2007, and is now 17.0% of the population [12]. According to HRF (Swedish National Association for Hearing-impaired), people with hearing disabilities exist of all ages. However, it is more common amongst older people (75-84 or 84+ years old) to have hearing disabilities, but the largest group is between 55-64 years old [12]. Also more than half of the people with hearing disabilities are working (ages 16-64) meaning that customizations of their workplace might be necessary [12].
Recently there have been rapid developments in products for people with hearing problems. There are three common aids: hearing aids, telephony, and alerting systems. Hearing aids have gone from a simple larger device embedded into glasses frames to ultra-thin delicate in-ear-devices. Telephones for the hearing-impaired were initially text based, providing a service called TeleTYpewrite (TTY), and via a relay-service could provide communication between a hearing-impaired person and a non-hearing-hearing-impaired person. Today these telephones support real time video, audio, and text – thus providing a TC-device (as described in Section 1.1). The one major category of aid that has not seen much development has been the alerting systems [15].
An alerting system is a system created to alert/inform the owner of an event in other ways than the original product allows, for example providing a flashing light for a telephone that normally signals an incoming call through an audio output (i.e., a ringing tone). Hearing-impaired and deaf people can use an alerting system to ease their everyday life, while avoiding the problems that might occur with ordinary products that have not been designed for these users [15].
2.1.1 Current Alerting Systems Technologies
To understand the technologies used today in alerting systems for deaf and hearing-impaired, a brief presentation of current products is helpful. Assistech [26] is a company specializing in finding appropriate assistive products for people with disabilities and special needs. Assistech is also a retailer of the most popular alerting systems, and their website has a wizard that helps user find and list these products. Some of the companies that Assistech mentions are: Bellman & Symfon [5], Clarity [6], Serene Innovations [8], SilentCall [9], and Sonic Alert [10].
By using the Assistech wizard to find the manuals of the different products, it is possible to determine what kind of technology the product uses. Assistech also states that an alerting system is built from senders and a receiver; where a sender sends a signal to the receiver that alerts the user in some way. Unfortunately, in most cases senders and receivers created by different companies cannot be used together, as they are not compatible with each other. One reason for this is that no standard exists for this communication. Assistech further claims that there are two kinds of technologies available for alerting systems: radio frequency and line carrier. Radio frequency technology sends signals wirelessly using radio waves where interference is avoided by altering the frequency or a numeric code for each device using a built-in dual in-line package (DIP) with several switches. This same technology was used in older garage door openers [17]. Line carrier technology
8 | Background
make use of the home (or office) electrical circuits to carry the signal between the sender and receiver [26].
Table 2-1 shows a list of technologies used by alerting system companies / products as stated in each product’s manual. These products either are described in the company’s technical catalog, as in the case of Bellman& Symfon, or are a new product released by the indicated company. The first column states the company’s name and the product that was examined. If a product is present, then the company’s entire catalog was looked at. From this table we can see that most companies use FM-radio configured via DIP-switches to pair their senders and receiver; although different frequencies are used by some of these products. Only Serene Innovations does something different, as according to the manual [27] their product CA-360 Visual Alert System use Smart-Code, although what Smart-Code is has not been documented. Also worth noting is that Serene Innovation’s product are not using Wi-Fi, although they are using the same radio frequency band as Wi-Fi. Furthermore, according to the manual you cannot put a CA-360 close to a regular Wi-Fi router, as they transmit and receive on the same frequency, but do not use the same protocol.
Table 2-1: Different companies and one of their newest products and which technology it uses. Note that a question mark is used when the frequency is unknown.
Company - Product Technology Frequency Manual
Bellman & Symfon FM-radio configured via
DIP-Switches 868.3 Mhz Technical Solution 1.4 [28]
Clarity – AL10 FM-radio configured via
DIP-Switches ? Clarity Alert Master AL10 [29] Serene Innovations
CA-360 Smart-Code 2.4 GHz Model CA-360 Visual Alert System [27]
SilentCall - SK2-SS
Sidekick II FM-radio configured via DIP-Switches 418 MHz SK2-SS Sidekick II Manual [30] SonicAlert – DB100 FM-radio configured via
DIP-Switches ? DB100 instructions [31]
The technologies presented in Table 2-1 either are old or do not following any standards (and sometimes they are both), but they are representative of alerting systems for deaf or hearing-impaired individuals. In contrast, one can look at alerting systems in the consumer market, where a very different picture is revealed. In the world of Internet of Things (IoT), with Internet connected everyday objects, several high tech solutions can do the same things as the products of the specialized companies listed by Assistech. See for example the Wi-Fi connect video “doorbell” products: Ring* and Skybell†. Moreover, code exists for Arduino and other platforms to make your own such device see example: http://lifehacker.com/5908850/build-an-arduino-powered-doorbell-alert-system-that-sends-you-a-text-and-photo.
Internet of Things (IoT) is a new term that has many different meanings in the literature. However, the words Internet and things suggest that IoT involves some kind of connectivity to generic objects (things) via the Internet using standard Internet protocols. This means that IoT consists of a word-wide network of interconnected objects using standard Internet communication protocols. Today a central issue is how these different things communicate with each other to create autonomous behavior that benefits users [32].
*https://ring.com †http://www.skybell.com
Background | 9
The market for smart everyday IoT objects is relatively new, but there exist many IoT products. For example, a Wi-Fi enabled light bulb that can be controlled from a computer or smart phone. Such a product is available from companies such as LIFX and Visualight [33], [34]. Home sensor systems integrate IoT products in the home to give the user more information about the home’s status and power consumption [4]. Additionally, some companies such as Spark [35], are enabling other companies to develop new IoT products by facilitating rapid construction of prototypes using existing modules.
When comparing the alerting system products made specifically for individuals with hearing problems and IoT products we can see some strength and weaknesses of the former type of systems. We will compare the following attributes for the two types of systems: signal range, security, and usability. First of all the range, FM-radio has (roughly) a fixed range depending on frequency and output power, while IoT solutions connected to the internet give an effective range that is only limited by internet connectivity (although the first hop range to get from the device to the Internet might be limited by the communication technology used for this link). When Internet connectivity is missing, then new hardware might need to be installed. As Internet connectivity is built out, the range and accessibility of IoT products are increased. As to security, IoT products are much more advanced as they can run on top of Wi-Fi, GSM, and 3G, which all have built in link layer security. Moreover, the devices can also make use of IP layer security (via IPsec), transport layer security (via SSL/TLS, secure real-time protocol (SRTP), Datagram Transport Layer Security (DTLS) …). The signals sent by FM-radio can be recorded and replayed, thus unintentionally or intentionally triggering alerting system receivers. The usability of IoT products differs between the different products. Different products use different ways to connect to internet, different higher layer protocols, and different applications to alter their settings. Alerting systems usually have at most some DIP switches that need to be altered, making them easier to install compared to some IoT products. On the other hand, alerting system components generally lack interoperability with components from other vendors, while IoT products can often work together or at least use the same signal receiver (typically a smart phone). IoT products can offer services that alerting systems for hearing-impaired /deaf cannot, as the former systems are connected to the Internet and hence can be integrated with many other systems - making them more flexible than the current alerting systems for deaf and hearing-impaired persons.
2.1.2 Omnitor AB´s new solution
The technological gap between modern day IoT devices and alerting systems for hearing-impaired and deaf people is an opportunity for companies delivering special telephones for the hearing-impaired and deaf – as these companies can potentially develop new products to fill this gap. Omnitor AB [11] is a company delivering modern IP-telephony systems with TC. New TC telephones run on tablets, smart phones and computers, enabling lightweight, compact devices with high quality video performance. The problem is how to connect a total conversation application running on a tablet (such as Samsung Tab S [36]) to an alerting system.
Today Omnitor offers two solutions for connecting a smart tablet: USB-alert [37] from Polycom and Bellman’s Mobile Phone Sensor [38]. USB-alert operates by closing a relay that is controlled via a USB interface. To activate an existing alerting system the USB-alert is connected to an alerting system’s transmitter that reacts to a closed a circuit (for example, a doorbell that actives when the button is pushed). This solution can be used with all alerting system that utilizes a sender that reacts to a closed circuit. A tablet using USB-alert must have support for USB-devices and must avoid problems with charging the tablet (when the USB-alert might be activated). Bellman’s Mobile Phone sensor is a small egg like device with a camera on it that is supposed to balance on the screen of your mobile phone (or tablet in this case). When the tablet screen lights up due to an incoming call the small egg acts as an altering system sender by sending signals through wires to a Bellman alerting
10 | Background
system receiver. Unfortunately, when using this product you are unable to use your tablet, because you cannot tilt or move it around, as the egg would then fall off. The Mobile Phone sensor is only compatible with Bellman´s alerting system products. Both products need wires to work, thus making the otherwise mobile tablet into a stationary device hence the user cannot move their tablet around.
Due to the weaknesses of current technologies, Omnitor AB required a new product to connect TC-devices on tablets with alerting systems. This new solution should not only resolve problems with connecting tablets to alerting systems, but should also serve as the missing link between smart IoT products and alerting systems. The idea is that this new product should bypass many of the problems of existing alerting systems problems, while also being compatible with them. This leads to the following requirements:
• Use standards (use standards as much as possible),
• Platform independent (the system should be able to be used regardless of the hardware or software the user uses for telephony),
• Smart (the system should be able to process data and just not be a simple circuit), • Cloud-based (the system should have the majority of its logic in the cloud, rather than
in the user’s end device(s)),
• Built-in security (compared to traditional alerting systems, this system should implement some form of security),
• Be compatible with current alerting system (if a user already has an alerting system at home, then the device should be able to connect to it), and
• Be compatible with IoT devices (if a user would rather use a smart light bulb than an alerting system receiver, then it should be possible to implement this use case using the new product).
2.2 Related Work
There are several things to consider given Omnitor’s interest in a cloud-based alerting system. The first is that currently there exist no similar products within the field of alerting systems that are specialized for the hearing-impaired and deaf individuals. Second, in other fields similar products may already be gaining popularity. For these two reasons, we need to examine related work.
2.2.1 Home Automation
Smart homes and home automation are two concepts that aim to offer users control over their home in order to increase their comfort, safety, and efficiency. One example would be to enable your refrigerator to know what is inside it, enabling user feedback and information about what products he/she needs to purchase. Another example would be to give the user control over all the lights in the house, as well as to program their behavior. [39]
A cloud based alerting system made for modern IP-telephony should work in the same manner as a very basic home automation system. When a total conversation phone receives an incoming call, other devices in the home could be activated. A lamp could be flashed or a traditional alerting system could be activated. The goal is that this new system should operate in the same manner as home automation system is triggered and activates or deactivates a device.
Andreas Hallberg and Oskar Lundh have written a paper on home automation as a an alternative solutions to environmental problems [40]. In their paper they discuss and show a simple
Background | 11
implementation for an home automation system that uses a Smart Phone and Raspberry Pi [41] together with remote controlled electrical outlets to control lamps and other mains powered devices. Figure 2-1 shows their setup as used in a simple home automation system. The central device is a Raspberry Pi computer that runs server software written in Java. This server handles incoming connection requests, stores state, and can on command send out a radio signal through a radio interface to turn on and off the different electrical outlets [40].
Figure 2-1: Home Automation Setup. (Inspired by Figure 1 on page 11 of [40])
The main advantage of using a Raspberry Pi as a server is that this computer supports many kinds of devices via USB, HDMI, RJ-45, and other standard interfaces. The device is credit card sized and energy efficient. The Raspberry Pi has a lot of support and been used in many hobby and professional projects. Several different operating systems are supported. The price of the Raspberry Pi is lower than many of its competitors, although some simpler devices, such as microprocessors are of course cheaper [41].
Using the Raspberry Pi as a server has both advantages and disadvantages. First of all the most obvious advantage is that by using an existing device there is no need for server hardware development. The main disadvantage is that all logic has to be implemented in this device, forcing it to store all of the settings and requiring greater performance from the device. Additionally, there may be problems when updating and altering settings if this process has to be done at every device. This is a particularly large problem if many devices are deployed. There is also a need to configure the firewall in the home router, especially if it uses Network Address Translation (NAT).
One of the alternatives to avoid the problems of NAT is to use IPv6, see for example the thesis project by Thor Hådén entitled IPv6 Home Automation [42] – where he realizes a home gateway to allow IPv6 control of devices attached to a RF controlled power strip. To securely reprogram IoT devices one should consider the methods proposed by Mussie Tesfaye, in his master’s thesis [43]. 2.2.2 Cloud-Based Services
One important concept that needs to be considered thoroughly is cloud-based service. The term “cloud” is often defined depending on what kinds of services are delivered. Cisco Systems, Inc. defines a cloud in this manner:
“A cloud is a powerful combination of computing, networking, storage, and management resources, enabling a new generation of consumer and enterprise IT services that can be available on demand and delivered economically to any device anywhere in the world without compromising security or function.” [44]
Many reports and papers have been written about clouds and cloud-based services. In the new solution desired by Omnitor, the cloud should be the backbone of the system, thus it will handle
12 | Background
most of the logic and the data of the system. This reduces the computational and networking burden on each of the individual devices, while maximizing the interoperability – as different data format and protocols can be supported by the cloud, without the need to modify the data sources (senders) or receivers
Amazon Web Services (AWS) [45] is internet based cloud computing infrastructure created by Amazon Inc. in 2006. AWS offers a huge variety of cloud based services that are scalable and offers a pay-as-you-go method where users pay for exactly what they are using, thus making the service very cost efficient and removing the need for overprovisioning of each individual service [46]. The following brief explanation of the different products and how they are related was taken from the list of products on Amazon [47]:
EC2 (Elastic Computing 2) EC2 provides virtual servers inside the Cloud VPC (Virtual Private Cloud) Provides a virtual cloud inside the Cloud to isolate
cloud resources from each other
CloudWatch A service used for monitoring resources inside the
Cloud
S3 (Simple Storage Service) A fully redundant data storage infrastructure for storing data on the web
RDS (Relational Database Service) Offers easy to setup database in the Cloud (MySQL, SQL Server, and many other databases are supported) 2.2.3 Single-user Profiles for Alerting Systems
In an article by Doris Jung and Steve Jones [1], they introduce the concept of a Graphical Profile Definitions Language (GPDL). GPDL is a simplification of linking alerting system with user profiles that triggers on specific events. Even though there exist similar solutions with XML/XPath, GPDL is unique in that their target group is the general population rather than specialists. Their article provides one example of how GPDL can be used. A library is connected to a notification system and the users defines their interests so that the library will notify the user when a certain book arrives. A user can then use GPDL to set the preferences for his or her interests.
The solution presented by Jung and Jones is a very general solution and not locked to a specific area. Comparing the GPDL solution for creating user profiles to connect with alerting systems with the alerting system solution requested by Omnitor, there are some major differences. GPDL is an interface for users to define profiles that alert the user via an already established alerting system infrastructure and triggering services. Omnitor’s new product is a link in the alerting system infrastructure connecting old technology with new technology, specifically by using Omnitor’s Session Initiation Protocol (SIP) server to provide triggering events. In its simplest form Omnitor’s new product does not need any user configuration, but when adding additional features to this new product user customization should be added and GPDL could be used for this.
2.3 Other related work
Related work that is used as inspiration and insight of how the system should be designed is of great value in this project. Omnitor’s new product must be designed with the ease of access and usage in mind. The entities that need to be designed have to be identified.
Background | 13
2.3.1 Remote Residential Control System
A remote residential control system is a home automation system, but on a higher level. Such a system is used to control different devices that in turn make the whole system control things, such as energy management, security surveillance, and consumer electronic. Ming-Shaung Lang has written a thesis on “Remote Residential Control System” [48] where guidelines to creating such a system are described and evaluated. This thesis discusses different standards for device communication and network management. The thesis ends with a brief review of trends and upcoming technologies. The thesis was written in 2004, but still has information that holds today. The thesis describes information about technologies that should be considered when designing a remote control system.
2.3.2 Service in the Cloud
In the thesis “Security as a Service in Cloud for Smartphones” by Laksmi Subramanian [49] in 2011 there is a detailed description of a cloud based solution. The idea behind this cloud service is to bypass the problems with battery life and CPU power that smartphones have. This is done by shifting some of the calculations to the cloud, focusing on processing on what is relevant to improving the security of smartphones. The thesis shows how the cloud can be used to provide functionality that otherwise would greatly limit the operating lifetime of the device.
2.3.3 SIP as Service Provider
SIP, defined in RFC 3261 [50], is a protocol used for starting, stopping, altering, and creating sessions. SIP has many uses, for example: internet telephone calls, multimedia distribution, and multimedia conferences. Omnitor’s new product is supposed to react to calls that are initiated through Omnitor’s SIP-Server. These calls initiate sessions that carry audio, video, and text.
In a master’s thesis by Martin Altinkaya and Saman Ahmedi from 2001 there is a presentation of SIP as a protocol as well as a description of how to use SIP for interconnecting and as a service provider [51]. In their thesis, the similarities between TCP and SIP are drawn, explaining the initiation of IP-telephony calls. One of the main goals of this thesis is how to solve interconnection between different protocols. The thesis concludes that connecting several different protocols by using SIP is possible, but the task would require a huge amount of work.
2.4 Summary
After exposing the problems with the technological gap between alerting systems for the hearing disabled and modern IoT products, a new solution is required. The new solution requested by Omnitor should be seen as the first step towards modernizing alerting systems. When comparing entities such as current alerting systems, IoT products, USB-alert, and Bellman´s mobile phone sensor we can see both advantages and disadvantages with the different systems. Table 2-2 lists the current solutions to the connection problem: tablet to alerting system, with both advantages and disadvantages.
The same type of summary can be done for simple implementations of home automation systems. Table 2-3 shows the advantages and disadvantages of different parts of the implementation of a home automation system. Note that these advantages and disadvantages were chosen to be relevant based upon the new alerting system requested by Omnitor AB.
14 | Background
Table 2-2: Advantages and disadvantages of different devices and their technologies.
Device Technology Advantage Disadvantage
Current Alerting System
Radio-FM Simple Implementation Unsafe
Limited Range. No compatibility
IoT Product Wi-Fi, GSM,
3G Secure, Reachable from Internet Can be connected to using API Wi-Fi needs to be setup Hard to implement
USB-alert USB to close
circuit Simple design Easy to use. Compatibility with other products
Prohibits the movability of tablets
Problem with support and power charging
Bellman´s Mobile Phone Sensor
Camera - Render device useless
while on it
Incompatible with other products
Table 2-3: Advantages and disadvantages of the implementation of home automation system.
Implementation Advantage Disadvantage
Raspberry Pi as
client controller Cheap and functional compared to other similar products Supports many different devices
Supports many different programming languages
More expensive compared to microprocessors
Run server on
user device Do not need back-end server Needs to manage all configuration and settings Hard to control many devices Needs firewall settings
Methodology | 15
3 Methodology
The purpose of this chapter is to provide an overview of the research method used in this thesis. Section 3.1 describes the research process. Section 3.2 focuses on the data collection techniques used for this research. Section 3.3 describes the experimental design. Section 3.4 explains the techniques used to evaluate the reliability and validity of the data collected. Section 3.5 describes the method used for the data analysis. Finally, Section 3.6 describes the framework selected to evaluate the prototype created in the project.
3.1 Research Process
As this project uses a qualitative research method, the research process itself has several steps containing examining and evaluation, often from the perspective of feelings, opinions, and reflection upon what has been done. The basic structure of the research process begins with an empirical research on the topic of already existing technologies and related work that can be useful for the design/implementation phase. After the empirical research phase, there will be a design phase in which different options are presented and evaluated. This evaluation is done by comparing the advantages and disadvantages of different designs with the list of requirements given by Omnitor (see Section 2.1.2). Following the design phase there will be an implementation phase. In this implementation phase the system is constructed resulting in a prototype. The final phase is the evaluation phase. The evaluation phase is the most important phase as it deals with collecting data from test users and interpreting this data. Based on the interpreted data, a detailed timeline for when new features could be introduced in updates or in a series of similar products is estimated. Figure 3-1 shows how the different phases relate to one another.
The empirical study is a straightforward phase as it simply looks at today’s solutions for alerting systems for hearing-impaired and deaf people. In addition, studies of Internet of Things (IoT) solutions will be done so the gap between these two technologies will be exposed. Related work, such as home automation systems and previous work on cloud computing is included in this phase. The goal of this phase is to gain a reasonable perspective on the current market, what technologies are used, and possible solutions that could be applied in the design phase.
In the design phase, some major decisions must be made. These decisions will affect the outcome of the whole project. The network architecture is to be decided upon; this is necessary, as different network architectures will affect the system’s design. The hardware for both the server and the client have to be decided. Lastly, the communication has to be designed, both in terms of protocol and data format (including individual fields and their encodings). All of the decisions in the design phase will have an impact on the implementation phase as the choice of hardware, protocol, and architecture may limit the system on many different levels.
Empirical
Study Gather ideas Check Similar Solutions Design
Phase architecture Choose hardware Chose Decide upon protocols Implementation
phase Implement Server Implement Client
Assemble Client Hardware
Implement admin-server
Evlatuion Feedback Survey Time Plan Detailed
16 | Methodology
Although all the different phases are equally important, the implementation phase is the largest in that sense it is expected that this phase will consume more time than the other phases. There are four different parts: the server, the client, the client hardware, and an administrative server. The client hardware needs to be assembled - unless there is a complete product at hand. For example, if the client hardware requires specific accessories to perform basic alerting system operation, then a peripheral will be used or another platform has to be considered. A basic alerting system operation could for example close a relay in order to activate the alerting system or turn on a light. The server, the client, and the administrative server have to be implemented through software development. This software development will use ideas from agile methods mainly scrum.
Scrum is an agile software development method that is drastically different from the waterfall model. In the waterfall model, development is streamlined going from point A to point B in a straight line. The waterfall model leaves little to no room for improvement as development takes place, hence only with great effort can such unplanned tasks be performed. The agile development methods tries to counter the problems of the waterfall model by putting emphasizes on collaboration, constantly having functioning software, exploiting flexibility, and adapting to emerging business realities. Agile methods are guidelines, while Scrum is an implementation of agile software development methods. Scrum provides concrete steps, specific improvements, and distinct roles. [52]
In the project the improvements adopted from scrum will be a scrum board, sprint iterations, and scrum meetings. The scrum board will be a collection of prioritized tasks that can be moved around, altered, and fixed. The board will be the main tool to ensure that development is on time and to decide what features are added or not. The sprint iterations divide the working period into short periods of about 2-3 weeks. Dividing the development into sprints increases flexibility. Each sprint begins with the selection of the tasks that together can create a minimal working version of the prototype. At the end of the sprint, the minimal version should be treated as a small release, which should be reviewed and critically evaluated. It is during this evaluation phase of the sprint that changes can be made and features can be added or removed. New changes can be applied to the next incremental version that will be implemented in the following sprint. During the scrum meetings tasks will be discussed and time for each task estimated. The scrum meeting will be held at least once per sprint, more meetings might be added if a particular problem occurs.[53]
The last phase is the evaluation phase in which the system will be tested by test users. These test users will be users with particular needs for such systems or users that have previously used USB-alert or Bellman’s Mobile Phone Sensor. After the test period is over, these test users will be given a simple survey (see Appendix A) where they can review the system as well as add information about it and in which direction they think the development should continue. The test users will be from different areas of Sweden: Stockholm, Karlstad, Uppsala, Örebro, and Linköping. Although the geographical distances are large, the number of participants is limited to one or two users at each location. It is important to have test users in different locations as different rules apply when it comes to aid distribution. Geographically distributed users will give a fair evaluation of the new product. The sparse number of participants is due to the limitation of hardware that can be produced for this project. Another limitation is also finding testers that uses Omnitor’s TC-device and can give high quality feedback. The feedback will be interpreted and used for creating a detailed timeline for when new features can be introduced.
The time for the project’s implementation will be divided accordingly (For the day-to-day work the scrum board is used). See Table 3-1 for duration of each of the phases.
Methodology | 17
Table 3-1: Duration for each of the four phases
Empirical Study 4 weeks
Design Phase 3 weeks
Implementation Phase 6 weeks
Evolution Phase 7 weeks.
3.2 Data Collection
The data will consist of feedback received from the test users. The format of the data should include some qualitative answers to a set of questions - along with answers to some open questions (that will enable the test users to write a small text as an answer). Some questions will have several alternative answers, but every question should have a field where the user can enter their thoughts in their own words. The data collection method, questionnaire and case study, fits this kind of evaluation. Both can deal with smaller groups and suit a qualitative research method. The questionnaire method supports both closed and open questions; hence, a questionnaire fits the data collection needs of this thesis project. Case studies are normally used together with the case study research method.
3.2.1 Sampling
Sampling will be done through an online web form where users can choose alternatives and fill out answers to open questions. The answers will be saved in a database and later examined. This database will be encrypted and the web form will be provided to the user using SSL/TLS to provide a secure channel, enabling the user’s input to be confidential and the data to be safely stored. The questions should answer the following questions:
• Type of user (Ordinator that orders the product*, Installer that installs the product for the user, User that actually uses the product itself)
• How easy is it to use the product?
• Which of the product’s properties are important? • What services should be added in the future?
• What other smart devices should be compatible with the product?
• Any other comments (There might be something that was never considered) 3.2.2 Target Population
The target population is limited to people who need to replace an USB-alert or Bellman’s Mobile Phone sensor. This group will be distributed over major cities across Sweden, specifically: Stockholm, Karlstad, Uppsala, Örebro, and Linköping. Each user will be provided with a prototype and the user has the opportunity to use it actively for two weeks before they answer the questionnaire. After two weeks, the user is expected to have been able to receive enough calls to build an opinion of the prototype.
18 | Methodology
3.3 Experimental design/Planned Measurements
To determine the research strategy, several different qualitative methods were examined. Both exploratory research and case study research methods were considered, as both are recommended for qualitative research, but neither of them fit the needs of this thesis project. Exploratory research was rejected as it uses surveys to gain insight into the problem and rather than exposing solutions, it focuses on finding key issues of the problem. A case study was also rejected due to use of an empirical investigation that did not fit the artifact development part of this project. [22]
The research strategy chosen for this thesis project is action research as it mimics the agile method used to develop software, more specifically in our case developing a small portion of the complete hardware and software system. Figure 3-2 shows the cycle used for action research, the steps are: take action, observing, evaluating, and critical reflection. [22]
When developing software with agile methods there exist some cyclic steps that work much in the same manner as action research. Figure 3-3 shows the entire software development life cycle. A user story is created and a plan for what it should contain in each release is discussed. When the release-planning phase is complete, then the software development process enters a loop of development and small releases, followed by feedback on all changes. Once a minimal product is created, the prototype system can be put into use although the loop of development and small releases may continue. Compare this to action research: the action taken is the development phase of the loop while observation, evaluation, and critical reflections are similar to the small releases. [54]
The research is driven by the requirements from Omnitor AB. Sets of ideas are proposed for a small release, then these ideas are sorted. Following this, an action is taken, leading to one of these ideas being implemented. Once this implementation is complete, then the result is presented and observation and evaluation take place. Before selecting more ideas to implement, critical reflection is performed. To ensure that the research is going in the correct direction changes and alterations can be proposed during the critical reflection phase.
Figure 3-2: Research strategy of action research
