This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENT

SERIES, December 2011. This is an author copy for personal record only.

RESTful Web Services for Service Provisioning in

Next Generation Networks: A Survey

Fatna Belqasmi*1, Chunyan Fu#2, Roch Glitho*3

*
Concordia University, Canada
1
fbelqasmi@[Link]
3
glitho@[Link]
#
Ericsson Canada, Montreal, Canada
2
chunyan_fu@[Link]

Abstract—Next Generation Networks (NGNs), as envisioned by introduced by new applications. [2] provides an overview of
ITU-T, are packet-based networks, capable of provisioning the ITU-T NGN vision and explains how the 3GPP IP
consistent and ubiquitous services to end-users, independently of Multimedia System (IMS) is a first step towards this long term
the network, the access technology and the devices used. vision. IMS is a key component of the third generation
RESTful Web services are now being contemplated as a
telecommunication networks that are currently being
technology for service provisioning in NGNs. They are emerging
as an alternative, which may be more adequate than SOAP- deployed. It is also a key component of the emerging fourth
based Web services in some cases. SOAP-based Web services are generation telecommunications networks. NGNs with varying
modular applications that can be discovered and invoked over a features have now been deployed by most telecommunications
network. RESTful Web services, on the other hand, are defined network operators.
as a network architectural style for distributed hypermedia Figure 1 depicts a generic NGN that embeds the ITU-T
systems. This paper presents a survey on RESTful Web services vision. It comprises a transport layer and a service layer.
for service provisioning in NGNs. It introduces the concept of NGNs decouple the service and transport layers as shown in
RESTful Web services and reviews the state-of-the-art of the figure. Furthermore, they provide support for generalized
RESTful-based-service provisioning in NGNs. It also provides an mobility, which enables end-users to communicate and access
evaluation of the overall suitability of RESTful Web services for services, independently of their location, and the access
service provisioning in NGNs, and discusses research directions.
technology and devices they use. In addition, NGNs endow
RESTful Web services do show significant potential for service
provisioning in NGNs. However, open issues such as end-users with unrestricted access to different service
publication/discovery and mechanisms for the development of providers, allowing them to access transport and services
complex session-based services need to be solved before its full provided by different business entities. NGNs support as well
potential can be realized. the provisioning of a wide range of services, including voice
(e.g. telephone service), data (e.g. Web-based services), video
Keywords— RESTful Web services, SOAP-based Web services, (e.g. IP-TV), and combined services (e.g. video telephony).
Next Generation Networks

I. INTRODUCTION
Next Generation Networks (NGNs), as envisioned by the
International Telecommunication Union (ITU), are packet-
based networks, capable of provisioning consistent and
ubiquitous services to end-users, independently of the network
and the access technology used [1]. The concept of NGNs has
emerged in the mid-2000s’ to provide a long term vision for
telecommunication networks after realizing that the first
generation of packet-based telecommunications networks
deployed in the early-2000s’ did not cater to all the needs
 This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENT
SERIES, December 2011. This is an author copy for personal record only.

Readers interested in the comparison between SOAP-based

Web services and RESTful Web services can consult [4].

II.1 SOAP-BASED WEB SERVICES IN A NUTSHELL

The SOAP-based Web service architecture [5] defines three
entities: service provider, service registry, and service
requester (Figure 2). The service provider creates a SOAP-
based Web service and publishes the service description in the
service registry. The service requester finds the service by
querying the service registry, retrieves the service description,
and then uses the description to bind to the service
implementation and start interacting with it. The service
registry aims at the on-line discovery of services. However, it
is rarely used today, because most requesters have prior
knowledge of existing services, thanks to off-line business
Figure 1: Generic NGN architecture agreements.
The communications (operations) among the three Web
Much work has already been done on the use of the SOAP- service entities are based on XML and use the Simple Object
based Web services for service provisioning in Access Protocol (SOAP). SOAP messages are commonly
exchanged over HTTP, even though other bindings are
telecommunication networks in general, including NGNs [3].
possible. The service descriptions are published using the
The use of RESTful Web services is now being contemplated. Web Services Description Language (WSDL). WSDL
The key reason is that RESTful Web services rely on Web provides information on how to use a Web service, including
technologies (e.g. HTTP, HTML) that are widely deployed a description of the service operations and binding
and could be easily re-used. This can only speed up service information. The most commonly used service registry for
provisioning in NGNs. SOAP-based Web services is the Universal Description,
SOAP-based Web services provide a standard means for Discovery and Integration (UDDI) registry. The UDDI
interoperating between software applications. RESTful Web specifications define a set of programming interfaces (APIs)
services are designed following the Representational State for both publication and discovery.
Transfer (REST) design style. REST, a technology neutral
design style, is defined as a network architectural style for
distributed hypermedia systems. Hypermedia systems enable WSDL Service
WSDL Service
WSDL Service
Description
WSDL Service
the storage and retrieval of information that may include Description
Description
Description
different media such as text, audio, video, and (hyper)links. Service Registry
RESTful Web services are being promoted as an (e.g. UDDI)

alternative that may be more adequate than SOAP-based Web

Find
services in some cases. Service provisioning remains a big WSDL Publish
WSDL Service
challenge and RESTful Web services may aid in tackling the WSDL Service
WSDL
Description
challenge. This is a key motive to evaluate the state-of-the-art Description
Service
in RESTful–based service provisioning for NGN, and identify
Service Requestor Service Provider
the research directions. It is the goal assigned to this paper. Bind
SOAP/HTTP
Section II gives an overview of REST, with conferencing
service as illustration. Section III discusses the state-of-the-art Figure 2: SOAP-based Web services architecture
of RESTful-based service provisioning in NGNs. Section IV
evaluates the overall suitability of RESTful Web services for The operations exposed by a SOAP-based Web service
the purpose and discusses research directions. We conclude in (e.g. createConference, addParticipant, in the case of a SOAP-
section V. based Web service for conferencing) are defined by the
service provider and each provider can define its own
II. REST OVERVIEW operations (i.e. an operation’s name, parameters and
In this section, we first introduce SOAP-based Web behavior). However, SOAP-based Web services can be
services seeing that they are very often contrasted with standardized as a means to increase interoperability; as with
RESTful Web services. The principles of REST are then Parlay-X multimedia conferencing Web service [6]. The list
presented, followed by the description of a RESTful Web of exposed operations is then included in the service
service for conferencing service used for illustration purpose. description.
 This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENT
SERIES, December 2011. This is an author copy for personal record only.

II.2 REST PRINCIPLES and split it into resources. After that for each resource we
REST adopts the client-server architecture of the web. proceed as follows.
REST does not restrict client-server communication to a • First, we name the resource using a URI.
particular protocol, but REST is most commonly used with • Second, we identify the subset of the uniform interface
HTTP because HTTP is the primary transfer protocol of the that is exposed by the resource.
Web. RESTful Web services can be described using the Web • Third, we design the representation(s) of the resource as
Application Description Language (WADL) [7]. A WADL received (in a request) from and sent (in a reply) to the
file describes the requests that can legitimately be addressed client.
to a service, including the service’s Uniform Resource • Fourth, we consider the typical course of events by
Identifier (URI) and the data the service expects and serves. exploring and defining how the new service behaves and
REST relies on three main design principles [8]: what happens during a successful execution.
addressability, uniform interface, and statelessness. For For a detailed description of these steps, the reader can
addressability, REST models the data-sets to operate on as consult [8].
resources, and identifies each resource via a URI. A resource
is any form of information that can be named and that is II.3 RESTFUL WEB SERVICE EXAMPLE
important enough to be referenced (e.g. a document, a row in The proposed illustrative service provides the same
a database, a search result). functionalities as the SOAP-based Web service described in
REST resources are accessed via a uniform and standard Parlay-X Multimedia Conference specification [6].
interface. A uniform interface offers a number of advantages Conferencing is one of the main services in NGNs.
among which are familiarity (i.e. the set of operations a The Parlay-X conferencing service is technology neutral
RESTful Web service may expose are known) and and allows applications to create and manage a multimedia
interoperability. Statelessness means that each REST request conference. The underlying model of the Web service is based
is self-contained with all the information that the server needs on three entities: conference, participant and media. The
to fulfill the request. No client-session data is stored on the conference is the uniquely-identified context, to which
server and the server never relies on information from participants can be added and removed. The participant is any
previous requests to answer a new request. The following party that participates in the conference. The media represents
advantages are usually associated with statelessness: easy the media stream to support a participant's communication
application development, good scalability, and easy load (e.g. audio, video, chat) and the stream direction (i.e. in, out,
balancing. bidirectional).
REST is not an architecture, but a set of design criteria. In this example, ‘conference’, ‘participant’ and ‘media’ are
Resource-Oriented Architecture (ROA) is a RESTful the data set on which to operate. For sake of simplicity, we
architecture that provides a commonsense set of rules and a focus on conference and participant. The data-set is then split
step-by-step procedure for designing RESTful Web services into three resources: ‘conference’, ‘list of participants’, and
following these design criteria. The fundamental mindset of ‘participant’. The first resource represents a specific
ROA is the concept of resources. Each resource has a name conference. The second lists the participants of the
(i.e. a URI) and a representation, and it may be linked to other conference, and the last represents individual participants.
resources via hyperlinks. A resource representation is what the The ‘conference’ resource is named with the URI:
client receives when it sends a request concerning a resource. [Link] confId being the
The representation can be defined as any useful information unique identifier of the conference, the ‘list of participants’
about the current state of the resource. An example in the case with: [Link]
of conferencing is the list of participants. and the individual participant with URI:
REST (and ROA) supports a wide range of representation [Link]
formats, including plain text, HTML, XML and JavaScript ntURI}/, since every participant is identified by his/her URI.
Object Notation (JSON). ROA uses HTTP as the The three resources can be read, created and deleted at
communication protocol. Therefore, the ROA uniform runtime. The first column of Table 1 lists the resources, and
interface consists of HTTP operations, the most commonly the second lists the subset of the uniform interface that is
used being GET, PUT, POST, and DELETE. We can design a exposed by each resource. The last column gives the
RESTful Web service using ROA in the following steps. We representations accepted from the client and those served by
first figure out the data set on which the service will operate, the server for each operation.
 This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENT
SERIES, December 2011. This is an author copy for personal record only.

Table I: Resource description and data representation

Exposed subset of the uniform interface Data representation
Operation
Resource HTTP action
Client->Server Server->Client

<conference>
[Link]
Create: establish a <description> discuss project </description>
POST: [Link]
conference <maxParticipants>10</maxParticipants>
</conference>
Conference Read: Get GET: [Link]
None <status>Active</status>
conference status
Delete: end a DELETE: [Link]
None None
conference

<participants>
<participant>
<uri>alice@[Link]</uri>
Read: Get list of GET: [Link]
None <status>Connected</status>
participants
</participant>
….
</participants>

List of <participant>
participants/ <participant> <uri>alice@[Link]</uri>
Create: Add a POST: [Link]
Participant alice@[Link] <link>[Link]
participant
</participant> participants/alice@[Link]</link>
</participant>
Read: Get a GET:
None <status>Invited</status>
participant status [Link]

Delete: remove a DELETE:

None None
participant [Link]

Alice Conf App

Figure 3 presents a sample sequence diagram that shows Bob
REST Client REST Server
what should happen during a successful execution of the
1 : POST([Link]
service. The client (i.e. Alice) sends a POST request to the
service URI, to request the creation of a new conference. The 2 : 202 Accepted([Link]

server creates a new ‘conference’ resource and sends the

The server creates the conference
resource URI to the client. When the conference is created and
the necessary resources reserved, the server sends a 200 OK 3 : 200 OK
4 : GET([Link]
message. In step 4 of the figure, the client asks for the
conference status, which she will get in the 200 OK response. 5 : 200 OK
In step 6, the client requests the addition of a new participant. 6 : POST([Link] bob@[Link])
She is first informed that the request is accepted, then she gets 7 : 202 Accepted

a 200 OK when the participant is actually added to the The server adds the participant(s) to the conference
8 : INVITE
conference. 9 : OK
10 : ACK

11 : 200 OK

Figure 3: Sample sequence diagram

III. THE STATE-OF-THE-ART

REST has been widely used outside of NGNs. Some
examples are read-only Web applications (e.g. static websites
and search engines), Amazon’s Simple Storage Service (S3),
twitter, and most of Yahoo!’s Web services. The use of REST
for service provisioning in NGNs is rather recent and includes
both standardization efforts and work done outside standards
bodies.

III.1 STANDARDIZATION EFFORTS

 This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENT
SERIES, December 2011. This is an author copy for personal record only.

Several bodies are attempting to produce standard

specifications for REST-based service provisioning in NGNs. Application Server
We review here the Open Mobile Alliance (OMA) and the 1 : POST outbound SMS request
IETF efforts.
SMS Create resource and allocate requestId
The OMA is working on a REST binding (ParlayREST) for
Parlay-X Web services. Thus far, the OMA has focused on sending 2 : Response with created resource including requestId

relatively simple non-session based services. The Short wait

3 : GET delivery status of request using requestId
specifications include Short Messaging, Multi Media
Messaging, Payment and Terminal Location Parlay-X Web 4 : Response with delivery status

Services. They have defined the resources and use HTTP as Inbound 5 : POST inbound SMS online subscription
their message transfer protocol. As for resource representation SMS Create resource and allocate subscriptionId
formats, XML and JSON are used for all resources, but other notification
formats may be used for some specific resources. 6 : Response with created resource incl. subscriptionId
The ParlayREST specification for Short Messaging Some time later
Service [9] is used in this paper for the purpose of illustration.
7 : POST notification to the notifyURL specified in the subscription
It provides support to:
• Send text messages to a terminal and check their delivery 8 : Response
At later time
status. To another 9 : DELETE the subscription
application
• Check, retrieve and delete the incoming messages. specified as
10 : Response

• Create and delete subscriptions for notifications for notifyURL

inbound/outbound messages.
Figure 4: Sample scenario for SMS handling
Table II summarizes some of the service resources, their
URIs and the operations they accept. In step 3, the application checks the delivery status using a
GET request sent to the URI of the newly created resource. In
Table II: A subset of ParlayREST SMS resources the second part of the figure, the receiving application
URL
subscribes to the notifications for inbound messages by
Resources
Base URL:
HTTP action sending a POST request to the URI of the ‘Inbound SMS
[Link]
on}/smsmessaging message subscription’. The server creates a new ‘Individual
Outbound SMS
/outbound/{senderAddress}/requests
GET: read pending outbound message
requests
inbound SMS message subscription resource’ and transmits its
message requests
POST: create new outbound messages URI to the application. The application may use this URI later
request
Outbound SMS
to delete or get information about the subscription. When the
/outbound/{senderAddress}/requests GET: read a given sent message, along
message request and
/{requestId} with its delivery status server receives a SMS destined to the application, it notifies
delivery status
Inbound SMS the application whose URI is specified in the subscription
GET: read all active subscriptions
message /inbound/subscriptions
POST: create new message subscription request, using a POST request.
subscriptions
Individual inbound GET: read individual subscription The IETF is working on REST-based approach for the
SMS message
subscription
/inbound/subscriptions/{subscriptionId} DELETE: remove subscription and stop
corresponding notifications
Centralized Conferencing Manipulation Protocol (CCMP).
CCMP is a stateless, XML-based, client-server protocol for
Figure 4 presents a sample scenario for sending and conference control [10]. The CCMP specification includes a
receiving a message. In the first part of the figure (i.e. SMS general (i.e. non-REST specific) discussion of the protocol,
sending), the application sends an ‘SMS sending’ request to and a discussion of a RESTful approach to the protocol.
the URI of the ‘outbound SMS message requests resource’, The CCMP allows users to create, manipulate (e.g.
using the POST operation. The SMS to be sent is included in add/remove participants, add/remove media streams) and
the request body. The server creates a new resource and sends delete conference objects. A conference object is a logical
its URI to the application (including the requestId). representation of a conference instance, representing the
current state and capabilities of a conference. The RESTful
approach for the CCMP uses HTTP as the transfer protocol
for CCMP messages, models the conference objects as
resources identified by URIs, and uses XML for data
representation.

III.2 WORK DONE OUTSIDE THE STANDARDS BODIES

Examples of work done outside the standardization bodies
are presented in [11] and [12].
 This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENT
SERIES, December 2011. This is an author copy for personal record only.

[11] discusses three approaches for exposing telecom first guideline is to incorporate Web 2.0 content (e.g. user-
capabilities (e.g. SMS, presence) with REST. The first generated video) and events (e.g. contextual information
approach uses an existing service delivery platform (SDP) as a associated with social networks) into telecom services. This
middle-layer over which the RESTful API is provided (Figure can enhance user experience and increase service
5). The SDP may belong to the NGN network operator or to a customization.
third party. The API can be built as an application inside the The second guideline is IMS services’ delivery via web
SDP that provides the necessary mappings to the actual pages. Web 2.0 technologies are used to build on-line
network elements that provide the capabilities to expose. This applications. The applications use directly the services offered
option has the advantage of lowering the integration effort of by the operator. An example is a virtual IMS terminal that
the RESTful API to the network capability. However, the SDP runs in an end-user’s browser. The major benefits here are
may become an unnecessarily heavy middleware if it is only service ubiquity, the reuse of the major advances achieved by
used to provide the RESTful API. Web 2.0 applications in the field of user interfaces, and a
significant simplification of the service development process
and deployment.

IV. SUITABILITY AND RESEARCH DIRECTIONS

We use NGN service provisioning requirements as
identified by ITU-T to evaluate the overall suitability of REST.
The requirements are presented first. The overall suitability is
then discussed in light of the requirements. Research
Figure 5: Integration via an SDP directions are discussed last.

IV.1 NGN REQUIREMENTS

The second approach is to have the RESTful API deployed Some NGN requirements impact all layers, including the
on a separate system that is integrated to the appropriate
service layer, while others impact only specific layers [1]. The
network element as-needed. This approach bypasses the SDP
main layer independent requirement deals with QoS and
overhead, but it requires substantial work on integration. The
security. A mechanism for end-to-end QoS should be defined
mapping layer is integrated with the RESTful API, which is
and security mechanisms should be provided to protect the
directly integrated to a specific network element.
exchange and the use of sensitive information, including
In the third approach, the RESTful interface and the service
authentication, authorization and encryption. The layer
logic are run as a standalone system, with no integration to the
specific requirements are discussed below.
operator network. One example is to provide a RESTful SMS
One fundamental requirement of NGNs is the support of a
service by integrating to a third-party SMS service provider.
wide range of services, and more specifically, making the
This approach allows for the service to be run by any party,
creation, deployment and management of all kinds of known
but it has the disadvantage of not allowing access to the
and unknown services possible and easy. This aspect includes
resources and information residing on the operator
enabling service providers (or operators) to find and reuse
network/system (e.g. subscribers’ information).
services offered by other providers (operators) to build new
[12] proposes a generic REST approach to expose the services. This requires support for service description, and
session-based capabilities of the 3G IP Multimedia Subsystem service publication and discovery.
(IMS). This approach models the sessions (e.g. multimedia Still another requirement is to allow for applications to be
sessions) as resources, and each resource represents a session based on service building blocks and functional entities. This
associated with a specific service. A conferencing session enables the reuse of existing services and allows the building
initiated by Alice for instance is named with of composed applications.
[Link]/aliceURI/Conferencing/sessionID. Each NGNs also require the support of a wide range of terminals
resource considers the session’s state, list of participants, such as telephones, cell phones, PDAs and laptops to access
media description and links to the session’s media the NGN services, which implies that client applications must
components. be simple and adaptive.
[12] also proposes an architecture for IMS and Web 2.0 The last requirement is to provide unified characteristics for
convergence, and discusses two guidelines for exploiting Web the same service as perceived by the user. This can be
2.0 services and technologies to enrich telecom operator’s provided via the provisioning of standardized and open
services. Web 2.0 is a concept that promotes interactive interfaces for the provided services.
information sharing and collaboration over the Web, as well
as Web application consumption by software programs. The IV.2 REST AND NGN REQUIREMENTS
 This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENT
SERIES, December 2011. This is an author copy for personal record only.

Regarding QoS and security, current RESTful Web In regards to open interfaces, there are ongoing efforts to
services are mostly based on HTTP, and therefore reuse the provide standardized RESTful APIs for telecommunication
HTTP best-effort QoS mechanism. In terms of security, the services (e.g. ParlayREST APIs). However, the fact that the
services rely on Web/HTTP security mechanisms, such as RESTful services may use different data models and resource
Transport Layer Security (TLS), to secure access to RESTful representation formats may result in interoperability issues.
Web services. HTTP defines two authentication and Therefore, the standard should also specify the data models
authorization schemes (i.e. simple challenge/response and and formats supported by each service.
digest authentication), but there is a standard means to In summary, RESTful Web services show a strong potential
integrate other authentication schemes into HTTP, such as the for service provisioning in NGNs. They meet most of the
schemes defined for SOAP-based Web services [8]. NGN requirements related to service provisioning. However,
Regarding the layer-dependent requirements, RESTful Web research remains to be done in certain areas in order to realize
services enable a wide range of end-user services because they its full potential. It is important to stress that extensions to
enable easier development and deployment of these services. REST may not always be required.
The development paradigm is based on the natural way the
Web works. IV. 3 RESEARCH DIRECTIONS
However, the development of complex session-based Research directions related to RESTful Web services
services may not be so obvious, due in part to the statelessness include open issues related to REST in general but pertinent to
of REST. This is especially the case for services for which the service provisioning in NGNs, and open issues specific to
server needs to maintain some states. One example is floor service provisioning in NGNs. A general open issue is service
control-based conferencing where a floor is granted to a publication and discovery. [14] talks about REST registries
requester only if nobody already holds it. It is important to where the RESTful Web services are published but it does not
mention that REST statelessness does not mean that the give any details about how the registry is designed or how the
service cannot have a state. The server can store and manage services are published and discovered. Before a client can start
the state of the resources it exposes. For instance, upon interacting with a RESTful Web service, it needs to know the
reception of a conference creation request, the server creates starting URI of the service and the representation format
the conference and maintains its state (e.g. the current list of accepted. The same applies for each of the service resources.
participants and the participant(s) that hold(s) the floor). The Currently, a client can discover such information offline, such
client can ask the server about the new state of the conference as from the service provider web site or by using a Web
at any time but the request is independent of any previous search engine.
request. The point here is to draw attention to the fact that Some potential approaches for starting URI publication and
designing session-based services with REST principles is not discovery are the use of an enhanced Domain Name System
straightforward. The design does require much more detailed (DNS) or the design of a RESTful Web services registry,
thought and consideration. However, the design of these along with the publication and discovery interface. Another
services does not necessarily require extensions to REST. research direction related to the design of a RESTful Web
For service publication and discovery, RESTful Web services registry is to adapt the SOAP-based solutions (e.g.
services can be described using WADL, but no appropriate UDDI and WSDL) to the specificities of RESTful Web
service publication and discovery platform has been defined services.
thus far. RESTful Web services also meet the requirement for A key open issue specific to service provisioning is
building blocks. Elementary building blocks can be composed resource-definition for complex session-based services (e.g.
into more complex Web services through mashups [13]. conferencing). Indeed, as discussed earlier, the design of such
Mashup is a Web concept where data, presentation or services is not obvious and resource definition is the corner
functionality from two or more sources are combined in order stone. Exposing session-based services with a stateless
to create new services. One example is to get a user location architectural style requires special attention. Furthermore,
using a location service and display it using a Google map. besides resource definition, there are other challenges related
However, the lack of an automatic service discovery to the provisioning of these services. An example is the design
mechanism limits the number of the composed services (we of enhanced features such as floor control.
can only compose the services we already know about). Parlay-X, for example, provides a specification for a
A RESTful Web service can be accessed by a wide range of conferencing SOAP-based Web service. However, to the best
end-user devices, including laptops, cellphones and PDAs. of our knowledge, there is no comprehensive RESTful
However, service adaptation to different devices without any session-based Web service, including conferencing. OMA
changes is not fully achievable. Nevertheless, depending on ParlayREST specifications do not cover session-based
the particular service, the adaptation level may be controlled services, and the CCMP work is still preliminary.
by limiting the client complexity (e.g. a simple service may be The conferencing service described in this article is a good
executed over a Web browser). starting point for a session-based service. It can be extended to
 This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENT
SERIES, December 2011. This is an author copy for personal record only.

provide more functionalities such as media manipulation (e.g. [2] K. Knightson et al, NGN Architecture: Generic Principles,
Functional Architecture, and Implementation, IEEE
add/remove/update a media stream) and floor control, by Communications Magazine, October 2005
defining new resources ‘media’ and ‘floor’ resources. [3] D. Griffin and D. Pesch, “A Survey on Web Services in
Potential approaches for notification support include using Telecomminications”, IEEE Communications Magazine, July
HTTP 1.1 persistent connections and long-polling, which 2007, Pages: 28-35
provide the HTTP server the possibility to push data to clients. [4] C. Pautasso, O. Zimmermann, and F. Leymann, “RESTful Web
Another open issue is the design of middleware that expose Services vs. “Big”Web Services: Making the Right Architectural
Decision”, In Proceedings of the 17th International World Wide
NGN capabilities via RESTful interfaces. This should respond Web Conference, pages 805–814, Beijing, China, April 2008,
to the requirement of having a common and open RESTful ACM Press.
interface to access these capabilities. It will also ease the [5] E. Newcomer, “Understanding Web Services: XML, WSDL,
development of new services based on these capabilities. A SOAP, and UDDI”, Addison-Wesley, ISBN 0-201-75081-3, May
Parlay- X gateway, for instance, is a standard way to expose 2002
the capabilities via a SOAP-based Web services interface, but [6] ETSI TS 129 199-12, Parlay X Web services; Part 12: Multimedia
conference, 3GPP TS 29.199-12 version 9.0.0 Release 9, January
to the best of our knowledge, no comprehensive RESTful 2010
middleware was proposed in the literature. [7] W3C Member Submission, “Web Application Description
A potential approach for designing a such middleware is as Language”, 31 August 2009
follows. First, identify the different mapping alternatives [8] L. Richardson and S. Ruby, “RESTful Web Services”, O’ Reilly
between the RESTful API and the capabilities’ interfaces. & Associates, ISBN 10: 0-596-52926-0, May 2007
Second, define a general mapping pattern that can be applied [9] Open Mobile Alliance, “RESTful bindings for Parlay X Web
Services –Short Messaging”, Candidate Version 1.0 – 27 Apr 2010
to most (or all) of the capabilities, if any. Third, optimize the
[10] M. Barnes et al, “Centralized Conferencing Manipulation
middleware performance. Protocol”, IETF draft, draft-ietf-xcon-ccmp-07, April 26, 2010
The approaches presented in [11] (and discussed in section [11] S. Mäkeläinen and T. Alakoski, “Fixed-mobile hybrid mashups:
III.2) can be used as starting point. The most promising experiences and lessons on applying the REST software
approach can be reused and eventually enhanced to provide a architecture principles to exposing mobile operator services”,
Proceedings of ICIN 2008 - the 11th International Conference on
suitable middleware. The middleware should mainly include a Services, Enablers and Architectures Supporting Business Models
mapping functionality, provide an easy to use interface and for a New Open World, NeuStar Secretariat Services, Bordeaux,
allow for easy support of additional network capabilities and France, October 20 - 23, 2008
nodes. [12] D. Lozano, L.A. Galindo and L. García, “WIMS 2.0: Converging
IMS and Web 2.0. Designing REST APIs for the exposure of
V. CONCLUSIONS session-based IMS capabilities”, The Second International
Conference on Next Generation Mobile Applications, Services,
REST has been widely used outside NGNs. However, and Technologies (NGMAST), 2008
several standards bodies are attempting to produce standard [13] C. Pautasso, “Composing RESTful services with JOpera”, Proc. of
specifications for REST-based service provisioning in NGNs the 8th International Conference on Software Composition,
volume 5634, July 2009, pp. 142–159
(e.g. OMA and IETF). Some work has also been done in the
[14] G. Jie1 et all, “Applying Recommender System based Mashup to
area outside standards bodies. Web-Telecom Hybrid Service Creation”, IEEE Global
RESTful Web services meet many NGN service Communications Conference (GLOBECOM) 2009, p: 1-5
provisioning requirements. They enable easy development and
deployment of a wide range of services, support a wide range
of terminals (e.g. laptops, cell phones), and allow for service BIOGRAPHIES
composition through mashups.
Fatna Belqasmi holds a Ph.D. and an [Link]. degree in electrical and
However, some issues are still open, such as RESTful Web computer engineering from Concordia University, Canada. She is a research
services publication and discovery, resource definition for associate at Concordia University, Canada. In the past, she worked as a
session-based services and the provisioning of an adequate researcher at Ericsson Canada. She was part of the IST Ambient Network
middleware. RESTful Web services do indeed show a great project (a research project sponsored by the European Commission within the
Sixth Framework Programme -FP6-). She worked as an R&D engineer for
potential for service provisioning in NGNs. Nevertheless, the
Maroc Telecom in Morocco. Her research interests include next generation
open issues need to be solved before their full potential can be networks, service engineering, distributed systems, and networking
realized. technologies for emerging economies.

REFERENCES Chunyan Fu currently works at Tekelec. She worked at Ericssion from

2008 to 2010 as a researcher and a services engineer. From 1997 to 2001, she
worked at China Mobile as a system integration engineer. She received her
[1] “Next Generation Networks – Frameworks and functional Bachelor degree in Computer Engineering from Nanjing University of Posts
architecture models”, ITU-T recommendation Y.2001, December
and Telecommunications. She received her [Link]. and Ph.D. degrees in
2004
Electrical and Computer Engineering from Concordia University, Canada in
2004 and 2008 respectively. During her [Link]. and Ph.D. studies, she worked
 This paper was published in IEEE COMMUNICATIONS MAGAZINE, NETWORK & SERVICE MANAGEMENT
SERIES, December 2011. This is an author copy for personal record only.

as an intern at Ericsson Canada. Her research interests include signaling, ad research, international standards setting (e.g. contributions to ITU-T, ETSI,
hoc networks, IMS and services in next-generation networks. TMF, ANSI, TIA, and 3GPP), product management, project management,
systems engineering and software/firmware design. He is a member of several
editorial boards including IEEE Network and IEEE Communications Surveys
Roch Glitho [SM] holds a Ph.D. (Tekn. Dr.) in tele-informatics (Royal
and Tutorials. In the past he has served as IEEE Communications Society
Institute of Technology, Stockholm, Sweden), and [Link]. degrees in business
distinguished lecturer, Editor-In-Chief of IEEE Communications Magazine
economics (University of Grenoble, France), pure mathematics (University
and Editor-In-Chief of IEEE Communications Surveys & Tutorials. His
Geneva, Switzerland), and computer science (University of Geneva). He is an
research areas include architectures for end-users services, distributed
associate professor of networking and telecommunications at the Concordia
systems, non conventional networking, and networking technologies for
Institute of Information Systems Engineering (CIISE), Concordia University,
emerging economies. In these areas, he has authored more than 100 peer-
Montreal, Canada where he holds a Canada Research Chair in End-User
reviewed papers, more than 30 of which have been published in refereed
Service Engineering for Communication Networks. In the past he has worked
journals. He also holds 24 patents in the aforementioned areas and has several
in industry for almost a quarter of a century and has held several senior
pending applications.
technical positions at LM Ericsson in Sweden and Canada (e.g. expert,
principal engineer, senior specialist). His industrial experience includes