A Framework for IMS Interworking Networks with Quality of Service Guarantee

dargspurΔίκτυα και Επικοινωνίες

27 Οκτ 2013 (πριν από 3 χρόνια και 11 μήνες)

223 εμφανίσεις



A Framework for IMS Interworking Networks
with Quality of Service Guarantee
Jinho Hwang, Nakpo Kim, Sangyong Kang, Jongseog Koh
Core N/W Development Team N/W Laboratory R&D Group KTF
hjh@ktf.com, npkim@ktf.com, david@ktf.com, jkoh@ktf.com

Abstract—The IP Multimedia Subsystem (IMS) could very
well be the best solution for most telecom operators. The more
recent releases have included interfaces to fixed line networks
and Wireless LANs. This has consequences both for the
migration of the core network as well as the integration of future
mobile services and applications. Also, an interworking between
IMS providers is considered to be a major step toward End-to-
End IMS services and IPX (IP Interworking Exchanged)
networks are introduced as the requirement to support QoS
features in GSMA. But these architectures don’t specify any
requirements for e2e QoS through IPX networks. This purpose
of this article is to research of IMS interworking Network for
enlarging IMS services guaranteeing e2e services quality and we
suggest the IMIN (IMS Interworking Network) framework to
guarantee IMS high quality end-to-end services.

Index Terms—IMS, IP interworking, e2e QoS, IP backbone
I.
I
NTRODUCTION
OWDAYS
Mobile communication services have been
developed from the CS(circuit switched) based services
to the service based on PS(packet switched) networks. And as
IP Multimedia Subsystem(IMS) defined as core networks in
3GPP has been adopted in many commercial networks, many
operators are developing various services based on IMS
networks.
According to having being evolved in 3G technology all
around world, 2G based operators have stated to be interested
in 3G wcdma networks and services developments. Especially
most mobile operators try to launch a new services based on
IMS networks. At the same time, fixed operators are
deploying Next Generation Networks based on IMS networks
and ISPs are offering an ever-increasing number of services.
Service providers need to maximize their connectedness
through interworking and roaming arrangements for their
subscribers to appreciate the full value of these services. Also,
various mechanisms for e2e QoS in other networks has been
suggested because services like VoIP based on PS between
different operators mainly have been developed. As a result
there is a need for an industry wide commercial and technical
interworking environment with e2e QoS guarantee to be set
up
Recently, the IPX which builds upon and extends the
architecture of the GRX was designed to be universally
applicable to different types of service provider. The IPX will
be controlled IP backbone that will interconnect Service

providers according to mutually beneficial business models. It
is designed to offer highly efficient and commercially
attractive methods of establishing interworking and roaming
interconnection arrangements for IP services.
But the IPX solution needs to optimize and specify a
framework for IMS Interworking Networks with Quality of
Service Guarantee. The goal of this paper is to research how
to guarantee IMS service quality in case of interworking
between different IMS networks. Especially, we address
existing ways of IP interworking and discuss the evolved IP
backbone networks for IMS services. Also, we define the
IMIN architecture in detail and explain main functions about
an IMIN server and an IMIN Resource Manager.
The remainder if the paper is structured as follows: In
Section II, we review IP interworking architecture in order to
explain the existing network to support IP interworking of
data service, which includes GRX networks and enhanced
GRX networks. Section III introduces the IMIN architecture
for guaranteeing high quality IMS end-to-end services and we
focus on each function of IMIN architecture. In Section IV,
we describe the interaction between each function and explain
call flows. In Section V, we summarize and conclude the
paper, and the short appendix contains a list of acronyms.

II. IP
INTERWORKING
A
RCHITECTURE

In this section, we first describe GRX networks, then
enhanced GRX networks and their requirements.

A. The GRX network of IP service interworking

1) IP interworking
The purpose of the inter-service provider IP backbone is to
facilitate interconnection between service providers, which are
need to maximize their connectedness through interworking
and roaming arrangements for IP traffic. Two possibilities
exist for interconnection between service providers.

Establishment of an inter-service provider IP backbone
connection via enter either GRX or enhanced GRX
providers
Direct connection between two service providers using
leased lines or internet using IPSec

N
Seventh International Conference on Networking
978-0-7695-3106-9/08 $25.00 © 2008 IEEE
DOI 10.1109/ICN.2008.69
454
Seventh International Conference on Networking
978-0-7695-3106-9/08 $25.00 © 2008 IEEE
DOI 10.1109/ICN.2008.69
454
Authorized licensed use limited to: TOKYO. Downloaded on June 16, 2009 at 05:58 from IEEE Xplore. Restrictions apply.


2) GRX concept
In 2000, GSMA established the GRX(GPRs Roaming
eXchange) network for the purpose of Mobile GPRS roaming
and only mobile network operators were allowed to connect to
it. The GRX provides connectivity based upon best-effort
between GSM and 3G Mobile network operators whenever
bilaterally agreed between those operators.

3) GRX Architecture
The GRX consists of separate and competing GRX
providers. A GRX network can be operated by any qualified
party. A simplified architecture of the GRX is illustrated in the
figure 1.



Fig. 1 GRX Architecture

GRX providers connect to each other via peering interfaces.
These peering interfaces may be direct connections. GRX
providers should enter into Service Level Agreements (SLAs)
with other GRX providers. Also, GRX network support a
common DNS root database used by all GRX parties and is
isolated from the public Internet and security rules are defined
to prevent unitended acces from it[1].
The GRX offers a transport-only interconnection service
between mobile operators on a bilateral basis with no
guarantees of QoS end-to-end. In particular, the GRX is used
to support traffic applications including IMS interworking.

B. The Enhanced GRX network

1) The Enhanced GRX concept
The enhanced GRX is called an IPX(IP eXchange) and is
designed to support a variety of types of service providers in a
secure and business sustainable way.

2) IPX Architecture
The IPX builds upon and extends the architecture of the
GRX by introducing a number of other stakeholders. The IPX
is formed from separate and competing IPX Providers[1,2].
Figure 2 shows the architecture of IPX.



Fig. 2 IPX Architecture
3) IPX Server system
Interworking between Service Providers can be established
with proxy services because of separation traffics. The
function of IPX proxy system is the most important in this
architecture because this function is aware of service feature
throughout signaling and traffic.
IPX Proxy system shall be able to forward media streams
and perform termination & initiation of media streams, when
functioning as a B2BUA, thus both SIP proxy and Media
Proxy should be aware of the media protocol and support the
mechanism that the media protocol used.

4) IPX requirements
a) Protocol
Evolved networks shall support UDP and TCP as transport
protocol, along with unlimited number of possible
media/application protocols (such as RTP, RTCP, HTTP,
MSRP etc). In other words, IPX networks should not place
any restrictions to supported protocols.
b) Addressing
Currently, the Inter-Service Provider IP Backbone networks
use IPv4 addressing and there is no plan to introduce native
IPv6 addressing in the foreseeable future. It is intended that
IPv6 is supported by tunnelling the IPv6 traffic over IPv4
between Service Providers where required.
Both IP Backbone Providers and Service Providers who
employ IPv6 in their network should assume full
responsibility for all network adjustments necessary for
maintaining connectivity to all other IP Backbone Providers
and/or Service Providers that deploy IPv4.
c) DNS/ENUM
The DNS/ENUM is completely separate from the DNS on
the Internet. The IPX Root DNS nodes that network operators
see are known as "Slave Root" DNS Servers and are
commonly provisioned by that operator's IPX service provider.
However, these Slave Root DNS Servers can be provisioned
by operators themselves if they so wish. Each Slave Root
DNS Server is synchronized with a "back end" Root DNS
Server known as the "Master Root". This is known as a "Zone
Transfer" and ensures that the data is the same in all IPX
Service Providers' and Operators' Slave Root DNS Servers.
d) QoS mechanism
Both UE(user equipment)s, GGSN in service operators and
IPX proxys in IPX providers support a Diffserv mechanism
and between service operator and IPX provider have to be
under contract to each other.

III. IMS

I
NTERWORKING
N
ETWORKS
A
RCHITECTURE

In this section, we suggest a IMS Interworking network
architecture, which is divided into a IMIN Server and a IMIN
455
455
Authorized licensed use limited to: TOKYO. Downloaded on June 16, 2009 at 05:58 from IEEE Xplore. Restrictions apply.


Resource Manager.

A. IMIN Architecture

Providing QoS to IMS services throughout IPX networks is
not just a bearer level issue. Not only is there a need for
involving the session layer but also for co-ordinating bearer
and session layer QoS. Also, it needs common resource
administration in order to collect and manage dynamically the
QoS and SLA information which is sent by each service
providers.
The IMIN architecture includes many IPX networks and a
common IMIN Resource Manager. And each of them has the
IMIN Server which is composed of three functions that are an
IS(IPX Server), an IP(IPX Policy) and an IG(IPX Gateway).
All of service operators and IPX providers have to connect
with IMIN Resource Manager to manage dynamic SLAs. The
main signaling and media components of the IMIN
architecture are depicted in Figure 3.



Fig. 3 IMIN Architecture

An IMIN QoS system is defined by contracts between
service operators and IPX providers. Whenever the SLA
information of each subscriber is changed, the Resource
Server of the corresponding operator communicates with the
IMIN Resource Manager dynamically to inform the modified
information. And then, the IMIN Resource Manger informs
the IP of the changed SLAs.

B. IMIN Server

The IMIN Server is composed of IPX Server, IPX Policy, and
IPX Gateway.

1) IPX Server
The protocol used in the IS is based on Session Initiation
Protocol and the components include the Parsing, the
Selection Database, the IPX/Service info, the Resource Check
and the Translation. This functionality of IPX server is
illustrated in Figure 4.


Fig. 4 The functions of IPX Server

When a session request comes in, the IS shall first check
whether a destination’s address is a domain included in the
same IPX provider or the other IPX providers in order to
forward the request. Throughout parsing the message, the
session information, that includes service provider, media
types, etc, is stored in IPX/Service info. And the Resource
Check give instructions to the IP defining how the IP shall
interact with the IG to act on its own, based on the service
information[6,7].

Parsing: To analyze the incoming SIP messages
Selection Database: Basic information to include both IPX
providers and Service operators
IPX/Service information: To store the result of parsing the
message
Resource Check: To interconnect with the IP to confirm
QoS information.
Transmission: To send the message into a destination.

2) IPX Policy
The IP makes policy decisions based on the policy
information obtained from the IS. It authorizes QoS resource
of Service Operator Information and Subscriber Profile
Information. If the requested resources of traffics exceed
SLAs in total resources according to each service operator, the
Admission Control which includes the limits on QoS rejects to
accept. Finally, the IP provides the policy decision
information to the IG[8,9]. The IP architecture is illustrated in
Figure 5.


Fig.5 The functions of IPX Policy

Policy Control: To confirm a contract session through
incoming session information
Admission Control: To decide to accommodate QoS traffic

3) IPX Gateway
An IP QoS architecture must be designed to provide QoS
guarantees beyond QoS differentiation. Delivering QoS
guarantees requires controlling the amount of traffic entering
456
456
Authorized licensed use limited to: TOKYO. Downloaded on June 16, 2009 at 05:58 from IEEE Xplore. Restrictions apply.


the network. In IMIN architecture this task is accomplished by
the IG.
Generally, the IG controls the user plane quality of service.
The IG contains Decision Rules that has the capability of
policing packet flow into other IPX networks or other IMS
networks, and restricting the set of IP destinations according
to a packet classifier that send the media traffic to Qos
pipes(EF,AF1/2/3/4,BE) by a scheduler[11,12]. Also, The IG
should be aware of the media protocol and support the
mechanism that the media protocol used, such as MSRP.


Fig. 6 The functions of IPX Gateway

Packet Relay: To forward media streams and perform
termination & initiation of media streams.

C. IMIN Resource Manager

The IMIN architecture distinguishes between resource
manager and admission control. The former refers to the
dynamic management of per-session bandwidth according to
SLA changes between service operator and IPX provider. The
IMIN Resource Manager monitor, control, and distribute
resource information of SLAs. With this architecture QoS can
be dynamically handled within a large IMIN domain. And the
IRM manages all operator/subscriber/subscription related
information needed for subscription-based policies. Table1
lists the information.

TABLE

I
Main Information needed for subscription-based Policies

I
NFORMATION
Description
Operator ID Service Operator ID
Subscriber ID Subscriber ID

Service ID Subscriber’s Service ID
Service List Subscriber's allowed service

Priority For each allowed service, a pre-emption priority
O_Max Bandwidth Information on Service Operator’s allowed QoS
S_Max Bandwidth

Information on subscriber's allowed QoS,
including the Subscribed Guaranteed Bandwidth
QoS
Charging Metering Subscriber's charging related information
Category Subscriber category

IV. IMS

I
NTERWORKING
N
ETWORKS
C
ALL
F
LOWS

In this section, we present the session Establishment and
Termination at the IS, IP, and IG.
A. Interactions between IS, IP and IG
This clause covers the interaction between IS, IP and IG.

1) QoS session Establishment


Fig. 7 QoS session Establishment

(1) The IS receives an external trigger to set-up of a new SIP session
and provide Service Information.
(2) The IS identifies the Service Information needed (e.g. service
provider of the session, port numbers to be used, information on
media types, etc).
(3) The IS provides the Service Information to the IP by sending a
Diameter AAR for a new Diameter session.
(4) The IP stores the received Service Information.
(5) If the IP requires subscription-related information and does not
have it, the IP sends a request to the Resource manager in order
to receive the information.
(6) The Resource manager replies with the subscription related
information containing the information about the allowed
services, QoS information.
(7) The IP identifies the SLA of a subscriber using the Service
Information received from the IS.
(8) The IP sends a Diameter AAA to the IS.
(9) The IP selects the Rules to be installed for the Session. The IP
may also update the policy decision by defining an authorized
QoS and enable the service flows of Decision Rules.
(10) The IP sends a Diameter RAR to request that the IG installs
Decision Rules and updates the policy decision.
(11) The IG installs the identified Decision Rules. The IG also
enforces the authorized QoS and enables service flow according
to the flow status of the corresponding Rules. If QoS information
is received, the IG shall set/update the upper limit for the MBR
that the IG assigns to the non-GBR bearer.
(12) The IG sends RAA to acknowledge the RAR. The IG informs the
IP about the outcome of the rule operation.


2) QoS session Termination

457
457
Authorized licensed use limited to: TOKYO. Downloaded on June 16, 2009 at 05:58 from IEEE Xplore. Restrictions apply.



Fig. 8 QoS session Termination

(1) The IS receives an internal or external trigger for a session
release.
(2) The IS sends a session termination request, Diameter STR, to the
IP to request the removal of the session.
(3) The IP identifies the affected Session where the Rules for the IP
flows of this IS session are installed. These Rules need to be
removed.
(4) The IP sends Diameter STA, session termination answer, to the
IS.
(5) The IP selects the Rules to be installed for the Session. The IP
may also update the policy decision by defining an authorized
QoS and enable the service flows of Decision Rules.
(6) The IP sends a Diameter RAR to request that the IG installs
Decision Rules and updates the policy decision.
(7) The IG remove the identified Decision Rules.
(8) The IG sends RAA to acknowledge the RAR.

B. IMS session Establishment
This clause presents the SIP based Session Establishment
and Termination.

1) Mobile session Establishment


Fig. 9 Mobile session Establishment using SIP

(1) The IS receives the SDP parameters defined by the originating or
within an SDP offer in INVITE signal.
(5) The IS gets the negotiated SDP parameters from the terminating
side through SIP signalling interaction.
(6) ~ (9) The IP interacts with the IG according to Decision rules.
(10) Upon reception of the acknowledgement from the IP, the SDP
parameters are passed to the originating side in 200 ok.

2) Mobile/Network initiated session Release


Fig. 10 Mobile/Network initiated session Release using SIP

(1) SIP BYE message is received by originating/terminating side.(a
SIP CANCEL request, a SIP 3xx redirect response, or any 4xx,
5xx, or 6xx SIP final error response is included in this case).
(3) ~ (6) The IP interacts with the IG according to Decision rules.
(7) ~ (8) Upon reception of the acknowledgement from the IP, the
SDP parameters are passed to the originating/terminating side in
200 ok.

V. C
ONCLUSION AND
F
UTURE WORK

This paper presented our research work on including the
function of the IMIN architecture in order to enlarge IMS
services guaranteeing e2e services quality.
We suggested the Framework for IMS Interworking
Networks with e2e Quality of Service Guarantee. They consist
of an IMIN Server to parse, decide and transmit signal/bearer
traffics and an IMIN Resource Manager to collect, forward
and manage QoS information. We also discussed the function
of each component in an IMIN Server. It is essential to
consider it to improve and guarantee e2e QoS in IMS
interworking through IP backbones because the existing IP
interwokring architecture doesn’t support e2e QoS. Finally we
highlighted the call flows for the IMIN architecture to process
the sip message and media traffic based on SLAs.
Currently, we research our architecture to improve and
specify the requirements including the Service Level
Specification (SLS) parameters in detail. The objective is to
improve policy-based management by integrating QoS
parameters into the SLSs.





R
EFERENCES

[1] GSMA PRD IR.34 "Inter-Service Provider IP Backbone Guidlines 4.1",
Jan. 2007.
[2] GSMA PRD IR.65 "IMS Roaming and Interworking Guidelines", Nov.
2006.
[3] 3GPP TS 22.173 "IP Multimedia Core Network Subsystem (IMS)
Multimedia Telephony Service and supplementary services; Stage1 R7",
Sep. 2007.
458
458
Authorized licensed use limited to: TOKYO. Downloaded on June 16, 2009 at 05:58 from IEEE Xplore. Restrictions apply.


[4] 3GPP TS 23.228 "IP Multimedia Subsystem (IMS); Stage 2 R8", Jun.
2007.
[5] 3GPP TS 24.229 "IP Multimedia Call Control Protocol based on SIP and
SDP (Release 8)", Jun. 2007.
[6] 3GPP TR 23.802 "Architectural enhancements for end-to-end Quality of
Service (QoS) R7", Jun. 2007.
[7] 3GPP TS 23.107 "Quality of Service (QoS) concept and architecture R7",
Jun. 2007.
[8] 3GPP TS 29.207 "Policy control over Go interface R7", Jun. 2007.
[9] 3GPP TS 29.208 "End-to-end Quality of Service (QoS) signaling flows
R6", Jun. 2007.
[10] 3GPP TR 29.213 "Policy and Charging Control signaling flows and QoS
parameter mapping R7", Jun. 2007.


A
PPENDIX
:

L
IST OF
A
CRONYMS


3GPP 3
rd
Generation Partnership Project

AAA AA Answer
AAR AA Request
AF Assured Forwarding
BE Best Effort
B2BUA Back-to-back SIP user agent
CSCF Call Session Control Function
CS Circuit Switched
DNS Domain Name Server
ENUM E.164 Number
EF Expedited Forwarding
E2E End-to-End
GBR Guaranteed Bit Rate
GRX GPRs Roaming eXchange
GGSN Gateway GPRS Support Node
IG IPX Gateway
IP IPX Policy
IS IPX Server
IMS IP Multimedia Subsystem

































[11] 3GPP TS 29.162 "Interworking between the IMS and IP
networks(Release 7)", Mar. 2006
[12] 3GPP TS 23.207 "End-to-end Quality of Service (QoS) concept and
architecture R7," Jun. 2007.
[13] Engel, T., et al., "AQUILA: adaptive resource control for QoS using an
IP-based layered architecture", IEEE Communications Magazine, Jan.
2003, pp. 46-53.
[14] Mykoniati, E., et al., "Admission control for providing QoS in Diffserv
IP networks: the TEQUILA approach", IEEE Communications
Magazine, Jan. 2003, pp 38-44.
[15] Sevasti, A., and M. Campanella, "Service Level Agreements
specification for IP Premium Service", Deliverable D2.1 – Addendum 2,
IST Sequin Project, Oct. 2001.





IPX IP Interworking exchange
IMIN IMS Intetworking Network
MBR Maximum Burst Rate
MSRP Message Session Relay Protocol
PS Packet Switched
RAA RE-Auth Answer
RAR Re-Auth Request
RTP Real-time Transport Protocol
RTCP Real-time Transport Control Protocol
SIP Session Initiation Protocol
SLA Service Level Agreement
SLS Service Level Specification
STR Session-Termination Request
STA Session-Termination Answer
TCP Transmission Control Protocol
UDP User Datagram Protocol
UE User Equipment
VoIP Voice over IP
WLAN Wireless Local Area Network



















459
459
Authorized licensed use limited to: TOKYO. Downloaded on June 16, 2009 at 05:58 from IEEE Xplore. Restrictions apply.