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 Internets 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
As Fig. 1 it is a common process of service development circle. But todays 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.
|| 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 users 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.
||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
||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 users 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 users 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 users perspective
to developers 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
|| 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
||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
||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
||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 SCEs 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 cant be formularized,
such as users comments and suggestion
|| 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 peoples 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.
||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 dont 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 users 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.
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.