Abstract: Next Generation Network is motivated by service which is related to human’s requirement. Current service related research focuses on how to discover or composite service. Few are directly related to human requirement research. Human requirement gathering is a complex task that is more than technology itself. In this study, technology probe is proposed to provide an easier way for service provider or developers to find out potential requirement of new service. Users are encouraged to use this technology probe, user activities will be corrected and analyzed. Based on the result, technology probe will provide service provider some new ideas on service requirement.
INTRODUCTION
Telecom is transforming and Next Generation Network (NGN) is treated as the opportunity to many teleco providers.
NGN/IMS provide different kind of capabilities which include high speed network and multimedia support. NGN/IMS provides people with high rate speed and multi-media support. But on the other hand, telecommunication industry is 'falling' comparing to Internet’s achievement. ARPU (Average Revenue Per User ) value reduces very quickly. As NGN can provide user with high speed network, multimedia resource it is treated as a transforming opportunity to many teleco providers.
Does NGN changes the way people use service? Would the new service be more attractive to users? Answer is not clear yet. Though network develops, service is still similar. In fact, during past three years, few new teleco applications or service become killer applications. So in this situation, network technology becomes more and more advanced but services applications still remain in a low level.
One of reasons that explain this situation is that user just cares about what application they can get and the interface they use but not the technology itself. There is not direct connection between service and technology. Technology is just a tool for service developer to implement service. And service is the one actually connects technology to user. Meanwhile, the connection is based on the service requirement.
Service means more than high-speed rate or multimedia. However, fewer researches are developed on how to improve service quality. And one of the most important issues in improving service quality or experience is how to gather service/user requirement.
In order to gather requirement directly, some media needs to be provided to connect user with developer, because there is no direct connection between end users and developers right now. All requirements are now gathered by some service departments and then sent to developers which disconnects direct connection between developer and clients. A new application/service might be out of date as soon as it is created.
In NGN service domain, researches also pay attention to user experience. This kind of research is called Quality of Experience (QoE) recently. However these kinds of research always focus on the middleware design. For example, how to provide a middleware that supports the QoE. So researchers provide lots of efforts on what the middleware looks like. How system changes when the requirement comes is one of researches topics. Some researcher focuses on providing context aware service framework (Strohbach et al., 2007). And some design Context aware Session Initiation Protocol (SIP) proxy to support adaptive service and requirement (Tang et al., 2008). As it is discussed, these research all focus on how to support dynamic context aware services. However, sometimes research become a “puzzle” which needs to introduce some AI or Semantic (Podobnik et al., 2007; Hong et al., 2005) technology. Those technologies (AI, Semantic, etc.) are cool. But it is not so practical when requirement changes frequently. Besides user always want to try something new and those technologies are not easy to adapt to new environment easy and quickly. In fact, gathering and understanding the requirement is the first step of implementing context aware service. And it is also the missing chain in the research.
As Fig. 1 it is a common process of service development circle. But today’s requirement and the design are not close enough. There is a gap between requirement and design. The reason is that there is no tool for people to connect dynamic requirement with design in NGN service domain. And even more, there are no tools for developer easy to gather in requirement.
How to gather human requirement is a topic in HCI domain. So some researches begin to use HCI concept to look into NGN service domain. It (Zheng et al., 2008) introduces a new framework of NGN service but it just maps some concept in HCI to NGN service domain. So it would be hard for real system to implement the framework.
In HCI domain, lots of researches apply some research result from other field, such as psychology etc. Technology probe is one of the concepts of HCI which comes from the culture probe (Gaver et al., 1999). “A probe is an instrument that is deployed to find out about the unknown-to hopefully return with useful or interesting data. There is an element of risk in deploying probes; they might fail or bring unexpected results”(Hutchinson et al., 2003) it designs a technology probe system for understanding how a big family uses technology to communicate with each other. That technology probe helps developer to think about designing new communication tools for family. Boehner et al. (2007) discussed about how probes should be like which includes “probes as data collection”, “probes as sensibility”, “probes as participatory”.
Technology probe in this study means a probe that is implemented for gathering user requirement from converged network and end user. The goal of technology probe is to help developers understand requirement and reflect the requirement on service development. And it might help to inspire some new service innovation.
In order to gather requirement more quickly and directly, this study introduces a technology probe for telecommunication network service development.
| Fig. 1: | A common life circle of teleco service |
MATERIALS AND METHODS
In this session, methods that include design principle and detail design of technology probe will be proposed. And before it is discussed, the position of technology probe would be discussed firstly.
Possible position in NGN service level: As it is known, NGN service level contains some important entities. Application server runtime and service creation environment are two major entities from the service development domain perspective. Telecommunication service is developed in Service Creation Environment (SCE) and then deployed in the application server (App Server).
Besides SCE and application server, there is Operating Supporting System (OSS). OSS is for supporting and monitoring telecommunication system status. In current system, OSS and application server are separated.
Telecommunication Service Technology Probe (TSTP) is used to provide an interface to connect user with developer. So TSTP would be related with the SCE and the OSS system. As Fig. 2, TSTP is on top of SCE and OSS system. In some sense, a SCE like interface is brought to end user directly, so that end user can easily influence the service development in a non technology way.
But as mentioned, technology probe is different from the SCE. It deals with user’s requirement and reflects to current service and system. Furthermore, TSTP would communicate with OSS, gathering some data from OSS which will be helpful for requirement gathering and service development.
| Fig. 2: | Position of technology probe in next generation network service layer (TSTP is short for telecommunication service technology Probe, SCE is short for service creation environment, OSS is short for operating supporting system) |
| Fig. 3: | A common software architecture of telecommunication service technology probe, SCE is short for service creation environment, OSS is short for operating supporting system |
From network operator's perspective, TSTP will connect existing system together. The integration of whole system would help operator to make some decision on service domain. For example, OSS data would be available to developers and some new application ideas might come from that kind of data. Meanwhile, as user’s service using data indicates user requirements. Developers use OSS data to understand the user requirement. And furthermore, after developers use OSS data, some reflects might be happened on the OSS system.
From end users’ perspective, TSTP would become a direct media for them to “talk to” telecommunication network and service. And this kind of communication helps them to get more customized application quickly. Besides, QoE of service might be improved.
From developers’ view, TSTP provides them requirement directly and quickly. So when there are some new requirements it is easy for developer to catch up with and do some further work on. The following part will introduce how to implement TSTP.
Detail design: As Part A discussed, TSTP is designed to connect users with developers and make developers easier to reflect on user’s requirement. The features of TSTP are as follows:
TSTP major features: TATP major features are discussed as follows:
| • | Providing user interface with end user and simulation of actual environment: This feature provides user a method to map/describe their everyday experience to system. System would provide some virtual environment for different situations, so users can provide their opinions on it |
| • | Data transformation and integration: End users and developers have different perspectives on service. As TSTP gets input from user and sends those information to developer, there needs some format transformation. The format transformation will transform data from user’s perspective to developer’s view. Data integration is to integrate data from OSS and other sources. Those data will also be transformed into same view |
| • | Statistics function: It is used to summary up all user's activity. This feature will help data mining data from user input and provide some summary information of inputs. There are three kinds of statistics information which will be discussed below |
| • | Scene creation function (creating scene for the end user): It is used to help end user easily to create a similar environment as they would like to describe |
| Fig. 4: | Telecommunication service technology probe graphics interface |
TSTP architecture: As features discussed above, the architecture of TSTP is designed as Fig. 3:
| • | The adapter module (includes SCE adapter, OSS adapter, other data adapter): It is for adapting with SCE and OSS. Adapter will gather information from OSS and Send requirement to SCE using some internal format |
| • | Requirement gathering module: It is a container like module. This module includes a requirement manager which is in charge of the module, managing instances. Requirement instance module is mapping with every users’ requirement input |
| • | Scene representation: It is a set of scene objects which covers most common scenes. It is a plug-in framework which can be easily extended |
| • | Scene creator and support module: It provides the function that organizes scene object together and record the whole procedure with internal xmL language |
| • | Graphical user interface (GUI) module: It provides interface for users to use the TSTP and represent logical view of the scene. Fig. 4 is a sample interface for TSTP |
| • | Data mining support module: It provides data mining function which includes how to combine different kind information together. Besides, this module will find out some potential patterns from data it has. It also provides overview of the data during a period of time. The statistics function includes how often capabilities are used which workflow is most used, etc. |
| • | API support module: It also provides a series of API functions for extension user to use |
The detail interactions between those modules can be found in next subsection (using model of TSTP).
Possible using model of TSTP: Figure 5 describes a common workflow of TSTP. User accesses to GUI interface of TSTP and he can create a scene or load a scene through scene manager. And then the entire scene will be associated with requirement manager. Requirement manager will create a requirement instance for this session. And requirement instance will deal with all following requests.
All user inputs will be translated into to requirement format in requirement instance. Requirement instance will use the function that “data mining support module” provides to transform the data into SCE’s data format. And after finishing these, all requirements will be represented to developers.
So Data mining function is one of the most important functions in above procedure. Besides, statistics function is another important function.
As mentioned before, there are three kinds information for statistics: one is capabilities’ usage; another is possible workflow information; and last one is the text description information:
| • | Capabilities using information shows which kind of capabilities users needs most and how is the capability used during different context |
| • | Workflow information provides some example workflows that are usually used in service |
| • | Text description information describes some ideas that can’t be formularized, such as user’s comments and suggestion |
| Fig. 5: | Modules interaction workflow of technology probe implementation |
“Capabilities using information” and “workflow information” will help developers choose which kind of service capability category would be widely used in the service.
“Workflow information” also gives developer a direct image of how people response to service and which kind of designs helps users more easy to use.
“Text description information” provides service innovation information. From people’s comments or suggestion, current service can be improved.
All information above will help developers understand how user is thinking on service. Besides, some more service related ideas might be developed through that.
RESULTS AND DISCUSSION
Lots of designs and concerns are talked about TSTP. In this part, a sample GUI is proposed to describe how TSTP should look like.
| Fig. 6: | Traditional telecommunication service creation environment (the creation environment connect different “functionality block” together to create a new application/service) |
Figure 4 describes a sample GUI for TSTP. This sample TSTP provides a scene environment which is used to describe a scene. On the left side, there are different categories. Each category stands for different option. User can easily drag some options to their corresponding targets.
After users finish their work; scenes will be imported into “requirement instance”. Requirement instances will then translate data format into the style which developer can easy to understand. Currently it is just an alpha design. Some properties will be added to connect between objects.
Figure 6 provides a description of a traditional SCE Interface which is more complex comparing to Fig. 4. As SCE is for detail design, all flows will be directly translated into some action sequence. However, TSTP is focusing on scenario which will be more general and easy for people to describe using blocks.
The advantage of TSTP is using data mining and statistics to gather requirement from users. And at the same time, that information will be provided to developers easily.
Comparing to existing research, this study tried to use technology probe to reduce the gap between end user and developer in NGN service domain (Boehner et al., 2007; Zheng et al., 2008) just create the basic idea but it don’t provide a framework or architecture. This study could help to develop NGN service from users’ perspective.
CONCLUSION AND FUTURE PERSPECTIVES
This study describes a technology probe concept of NGN. And some possible architecture and working principle are discussed. It would be helpful for developer to use technology probe to explorer requirement. Besides, some new ideas on service might be generated from this technology probe.
In future, the study will focus on implementing the whole TSTP and doing user study on it. So challenges would be as follows:
| • | How to merge and transform data together |
| • | How to find out some common workflows from interface and user activities |
| • | How to represent interface. As different people have different understandings of service, especially between users and developers |
| • | How to measure effects of TSTP, from developer and end user’s perspective |
First two challenges mostly come from technology aspect. Data mining or statistics algorithm could be used to accomplish them. And last two challenges are HCI challenges. Some parameters and measurement principles need to be setup. Focus group or interview is also needed.
ACKNOWLEDGMENT
Thanks lots of support from China National Science Foundation, Grant No. 60821001, No. 2011AA01A102, No. 61121061, No. 61003067 and all the colleagues from National Lab of Networking and Switching Technology and the Ubicomp Lab in Georgia Tech.