ITU Centres of Excellence for Europe

NGN Services VoIP and IPTV

Module 2:

NGN VoIP: technologies, regulation and business aspects

1

Table of contents

2.1. VoIP numbering and addressing in NGN.......................................................2 2.2. VoIP Quality of Service (QoS) .....................................................................11 2.3. IMS-based VoIP for NGN.............................................................................24 2.4. VoIP over wireless and mobile networks .....................................................31

2.4.1 VoWiMAX ...........................................................................................32 2.4.2 VoWLAN.............................................................................................38 2.4.3 VoIP over 3G/LTE/LTE-Advanced ......................................................44

2.5. VoIP over DSL and FTTH............................................................................49 2.6. Next Generation VoIP architecture ..............................................................57 2.7. NGN VoIP regulation and business aspects ................................................68 References .........................................................................................................76

2

2.1. VoIP numbering and addressing in NGN

Ever since the introduction of telephony (voice) services, numbers have

played a crucial role in making calls. As well as fulfilling the key functions of facilitating the correct routing of calls and levying of call charges, the role of telephone numbers has been extended in many countries to include aspects such as value-added services, where a particular number or number format becomes an effective part of the branding of the service, and consumer protection through the regulatory adoption of distinct numbering ranges for differently-priced types of calls, e.g. geographic, mobile, premium etc.

The introduction of competitive NGN telecommunications operators and suppliers within countries further increased the importance of numbering resources as a regulatory instrument. This has had the effect of creating a de facto Numbering Paradigm where:

- network operators require numbers to implement services - whoever controls the numbers - controls competition => no numbers = no service => no service = no competition Indeed, experience internationally suggests that increasing competition

leads to more rapid innovation of telecommunications products and services, which in turn places further demands on the numbering resource, and demands its fair and efficient functioning.

When it comes to VoIP numbering and addressing in NGN - NGN is intended to provide an efficient, secure and trustworthy numbering, naming and addressing environment for VoIP users, network operators and service providers. Regulatory requirements as well as interoperability with PSTN/ISDN will be taken into account where applicable, since the NGN consists of interconnected heterogeneous networks, using heterogeneous user access and heterogeneous user devices. Evolution to NGN is required to ensure that the sovereignty of ITU Member States with regard to numbering plan, naming plan, and addressing plans is fully maintained, in particular as described in [ITU-T E.164] and other relevant Recommendations and Specifications of other standard bodies.

In the old PSTN the ID is the E.164 number and that number is used for identifying and routing the call to the subscriber/user or services. With the introduction of services based on non-geographic numbers and number portability the function of the number has been split between a name role for identifying the user or service and an address role to indicate how to route the call to the subscriber's network termination point. In the UMTS based mobile networks several additional identifiers are used to identify the user:

Public ID(s), Private ID and Home Domain ID, described in TS 123 003. Additional applications like UMTS Subscribers Identity Module (USIM), and the IM Services Identity Module (ISIM) are used for user access in the network.

3

Furthermore, in circuit switched networks there are also some IDs used for different network functions, like for example Signaling Point Codes for the ITU-T Signaling System No. 7 (SS7). In GSM-based PLMNs the E.164 number is often called an MSISDN to indicate that the E.164 number is used for mobile services. Another ID used in GSM networks is the IMSI, based on ITU-T Recommendation E.212, providing a unique identifier of the mobile subscription for registration purposes. Most of the present SIM cards used in GSM networks are marked with another ID called the Issuer Identifier Number (IIN) according to ITU-T Recommendation E.118.

For Internet and other IP based networks, at the beginning only IP address was major ID. Later, names in the form of Domain Names according to RFC 1035 are used. The Domain Name is used to identify the user/host and the IP address used for routeing to the interface to which the host is connected.In the context of an NGN, E.164 numbers need to be translated into other kind of IDs (e.g. IP addresses) usable within the NGN.

Many network operators across the world are in the process of migrating their core network from the traditional circuit-switched network to IP-based NGN. With the emergence of NGN, new numbering, naming and addressing schemes may be introduced for new service applications. In recent years, fixed and mobile network operators have started migrating their networks to IPbased NGN which can offer a number of advantages over the circuit-switched network. Such migration is expected to continue for some years. Being the dominant scheme within voice communications to identify and connect users, the E.164 numbering scheme is expected to continue, at least in the short to medium term, under the NGN environment.

Moreover, individual users may be identified by name/numbers using a name/number resolution system which will be able to translate a given name/number into a routable and valid address in order to establish a transfer (transport) facility (connection or flow).

Examples of such numbering and addressing schemes for service applications in NGN (including VoIP) may be:

� E.164 numbering scheme; � Unified Resource Locator (URL) scheme; � Unique name system (e.g., 1800Airways etc.); � Electronic Number Mapping (ENUM) � or other naming conventions such as H.323, SIP, telephone and

mail unified resource identifier (URIs (Unified Resource Identifier)). Use of international character set for URIs is for further study.

A user who requires access to another user may directly input one of the above-mentioned identifiers and then either the terminal or the network may translate the user input into an end-point address, either using a network internal database or a network external database (for example, accessed via a DNS (Domain Name System) translating mechanism). Moreover, NGN should be able to provide name and number portability.

Furthermore, as one example of future possible NGN scheme for numbering and addressing in VoIP is ENUM with domain name. ENUM is a

4

protocol developed by the Internet Engineering Task Force (IETF) for mapping an E.164 number into a collection of service specific Uniform Resource Identifiers (URI) that are based on the Domain Name Server (DNS) architecture in the IP environment. Under the public ENUM, an E.164 number e.g. +1 613 829 7277 is converted into:

“7.7.2.7.9.2.8.3.1.6.1.e164.arpa” where “e164.arpa” is the public ENUM top level domain.

The advantage of public ENUM is that users may use a single number to access a wide range of terminals and services, such as phone, fax, email, web or any other services available through an Internet addressing scheme in the NGN world. With the migration of the existing circuit-switched PSTN to IP-based NGN, public ENUM may be one of the possible schemes to facilitate interoperability for a wide range of applications such as voice, video and instant messaging by using E.164 numbers.

In following are the requirements to support numbering, naming and addressing capabilities in NGN. Except where noted, they apply to both the transport and service strata.

General requirements for numbering, naming and addressing 1) Both dynamic and fixed address assignment modes are required to be

supported. 2) Numbering, addressing and naming capabilities may be implemented

by using an individual mapping scheme for each service, or via a mapping scheme that is common across different services.

3) Dynamic update of naming databases is required to be supported (for example, in case of a mobile terminal, addresses at one or more layers may dynamically change depending on the terminal's location).

Moreover, as a public operation network, the NGN shall meet the following key requirements for the name/number/adress resolution (resolution [ITU-T Y.2001]):

� Reliability: The name/number resolution system is directly related to the running of the NGN, so it should have carrier class reliability. It shall have two capabilities in the architecture. First, it should not be a single point of failure. Secondly, it should have excellent load balancing mechanisms. Good configuration and arrangement shall be conducted to meet the capacity requirements during the network planning.

� Integrity: While the name/number resolution system is directly related to the running of the public networks, it must be ensured that the name/number resolution systems will not conflict to each other and that the overall name/number translation databases will have only valid and reliable entries so that the whole system will not be affected in its integrity, especially when distributed systems are used.

� Security: The name/number resolution data are important network data that may directly impact the operation of the network, and they are also sensitive commercial data reflecting the structure and

5

policy of the network operations. Accordingly, the name/number resolution system shall be a special system used only by this network, and certain security measures shall be in place. The security is mainly maintained by the means of user access authentication, data security, data privacy, network data synchronization and fault recovery.

� Sovereignty: While the network and the name/number resolution systems are designed to provide national and global services, it needs to be ensured that the sovereignty of an affected country to govern is not questioned.

� Numbering

The numbering requirements applicable to NGN are the following: 1) Addressing mechanisms are required to support the ability to

differentiate between the dialling plan, numbering and addressing plans. 2) Addressing mechanisms are required to support the ability to translate

a dialling sequence into the numbering and addressing scheme. 3) NGN is required to support E.164 numbering (global numbers). 4) NGN should allow non-E.164 numbering (local numbers). 5) NGN should allow short numbers in national dialling plans. 6) NGN should not prevent private and corporate numbering. 7) When non-E.164 numbers (local numbers) or dialling sequences are

used, NGN addressing is required to provide the scope within which the local numbers are valid.

8) NGN is required to support the ability to differentiate alphanumerical identifiers that happen to be consisting of only digits from those which are telephone numbers and should be treated as such in routing procedures.

� Numbering, naming and addressing NGN release 1 VoIP schemes

1) At the transport stratum, NGN release 1 is required to support IP addressing schemes based on IPv4 or IPv6 or both ( It should be recognized that a mixture of IPv4 and IPv6 within a single domain may cause problems for service delivery).

2) NGN release 1 domains may support user equipment using IPv4 only, IPv6 only or both at the User-Network Interface (It is assumed that IPv6 based user equipment can also support IPv4 at the User-Network Interface).

3) NGN release 1 is required to support IP multimedia communication establishment (in both the originating and terminating case) using at least E.164 telephone uniform resource identifiers (Tel URIs), e.g., tel: +4412345678, and SIP uniform resource identifiers (SIP URIs), e.g., sip:my.name@company.org, as a minimum. For Tel URIs:

– global numbers are required to be supported; – local number form should be supported. 4) In some service scenarios, e.g., interworking with PSTN/ISDN, an NGN

release 1 is required to support IP multimedia communication establishment (in

6

both the originating and terminating case) using E.164 numbering with ENUM-like support where appropriate.

5) Numbering and addressing schemes are required to support unicast and multicast service types.

6) Numbering and addressing schemes should support broadcast service types.

7) Other numbering, naming and addressing schemes may be supported.

� Numbering, naming and addressing interworking The interworking functions perform translations of numbers, names and

addresses when required in network interconnection scenarios. 1) NGN is required to support multiple transport stratum address

interworking scenarios without affecting the service provided to users (i.e., interworking scenarios among different addressing domains, such as domains based on IPv4 or IPv6 addressing schemes, and domains based on public or private addressing schemes).

2) Where needed, address translation capabilities are required to be used to support address format differences, in both the transport and service strata, without affecting the service provided to users.

� General requirements for Identification, authentication and

authorization There are requirements for bilateral identification, authentication and

authorization capabilities in both the transport and the service NGN stratums. In the transport stratum there are requirements on how NGN transport resources can be used. In the service stratum requirements are on the association between a user and a service or between a user and another user, including the case when the two users are on different NGNs (Sometimes the phrase "service provider" has been used to refer to the provider of transport stratum services). In this section, the network provider is usually shortened to "(the) NGN", and the "service provider" is exactly that, the "provider of the service": the service provider could be anywhere, and is not necessarily the network provider.

The following are general requirements for identification, authentication and authorization capabilities:

� NGN is required to support bilateral authentication and authorization functions for both the transport and the service strata. Transport stratum authentication requires a user to be identified by the network in order to obtain access to the network and to privileged uses. An authentication function can be a significant factor in protection from unauthorized use of networks, such as prevention of unsolicited bulk telecommunications. An authorization function can set up access to network resources and prevent access violations.

� NGN is required to uniquely identify users by one or both of the following types of user identifier:

– public user identifier: The information that is normally used by one NGN user to contact or communicate with another NGN user;

7

- private user identifier: A private NGN user identifier can be used to identify the NGN user to her/his NGN network or service provider. The private user identifier is one component used for authentication.

� NGN is required to allow separate identification, authentication and authorization of users and terminal equipment.

� NGN is required to allow verification of the association between the user and the user's terminal equipment for some specific services.

� Authentication, authorization and accounting, performed by the NGN provider and the service provider, should be processed securely.

� A service provider is required to provide mechanisms that allow presentation of the public identifier of the communication originator, where appropriate and where permitted.

� A service provider is required to provide mechanisms to withhold the public identifier of the communication originator, if the presentation of this information is restricted by the communication originator or the network.

� A service provider that performs authentication is required to support mechanisms to determine the authenticity of a public user identifier presented for an incoming communication.

� A service provider that performs authentication is required to provide mechanisms that allow the presentation of the public user identifier of the connected party to the communication originator, if applicable and if this is not restricted by the connected party or the network.

� An NGN is required to be able to verify the private identifier of users and terminals (if applicable). Additionally, it is required to be able to check the authentication and authorization of users and terminals to use resources of the NGN.

� A service provider is required to be able to verify the private identifier of users of the services it provides. Additionally, the service provider is required to support the capability to check the authentication and authorization of users to use resources it manages.

� Private and public identifiers of NGN users of transport stratum resources (identifiers used for authentication and authorization) are required to be administered by the relevant network provider.

� Private and public identifiers of service users of service stratum resources (identifiers used for authentication, authorization and routing), are required to be administered by the relevant service provider and such administration is required to prevent the user from unauthorized changes to the public and private identifiers.

� Private NGN user identifiers provided for authentication and authorization are required to be withheld from other users.

� Public NGN user identifiers of service users may be visible to other users if no service intermediaries are involved and the user's permission is given.

� A service provider may allow a user to access a service from multiple terminals in parallel using the same public and private user identifier.

8

� As a single user may use multiple private user identifiers via a single subscription procedure, the NGN is required to support multiple private user identifiers via a single subscription procedure.

� NGN may authenticate and authorize a single user for multiple services ("single sign-on") - Even when only a single authentication event is required, multiple authorization events may still be needed. In addition, single sign-on can be implemented on the client side, such that even though multiple authentications are required, the human user only needs to establish an authentication relationship once. NGN release 1 does not require support of single sign-on capabilities. However, where such support exists with current technologies, it is expected to be also used for NGN release 1. Authentication of a subscriber's identifier or of a user's identifier is not intended to indicate positive validation of a person.

� Requirements for identification

The NGN release 1 provides capabilities for user identification, in order for network operators and service providers to identify the users of certain NGN VoIP service and use this information as required (e.g., for authentication and authorization procedures). NGN release 1 is required to provide capabilities for the user to identify NGN providers (on each stratum) where a direct relationship exists. In that context in Table 2.1 is given an overview of Identifiers.

Table 2.1 Overview of Identifiers

NGN Layer

Format of the Public ID within the network

Private ID (Network Aware)

Public ID (User aware)

SIP URI ID stored in ISIM Name(s) User/Service Identifier

Service tel URI SIP URI with domain operatorprovided

ID stored in ISIM or derived from USIM

Number(s)

Network Identifier

Transport Number, and Routeing Number IP Address

Network ID Line ID

Address

Requirements for identification capability for any NGN service (including

VoIP) include the following: 1) Multiple user identifiers: As an NGN user may have one or more public and private identifiers, NGN is required to segregate one identifier from another (e.g., for personal use and business use). 2) Identifier portability: NGN is required to provide capabilities that provide the equivalent of number portability in PSTN environments. 3) Identifier independency: The public user identifier should be assigned to the user independent of its repository, the user terminal and the underlying

9

network technologies. However, backward compatibility (e.g., for POTS handset) may be achieved via proper interworking functions. 4) Support for identifier attributes: Private identifier attribute, such as the lifetime of that identifier for the user, the subscriber, the network in use, etc., may be associated with a user identifier. 5) Support for attribute conditions: Conditions (e.g., setting timer as validity conditions) for a user attribute may be associated with a user identifier by an attribute provider (e.g., network, principal user, end user). 6) Selective attribute authorization: NGN is required to support selective authorization of user's private identity attribute information by an attribute provider (e.g., identifier lifetime). 7) Support for subscriber programming: NGN should support subscriber's programming of different permissions for different attribute information, e.g., access to and usage of private identity attribute information, on a per attribute basis. 8) User and terminal binding: NGN is required to support a dynamic binding of the public user identifier and the terminal equipment identifier for certain services. 9) Multiple terminal association: NGN is required to allow association of a user public or private identifier to multiple (mobile or fixed) terminal equipment identifiers for certain services. The user may be allowed to use multiple terminals at any given time. 10) Identifier information transfer: NGN is required to support the transfer of the user identifier information by NGN users if permission is given by the user providing input either on their own terminal or on the receiving terminal for certain services (e.g., point of sale terminal).

� Requirements for authentication in NGN Authentication is the process of establishing confidence in user and terminal

equipment identifiers as well as network attachment and service offers. From the point of view of providers, NGN may distinguish between transport network authentication and service (VoIP) authentication. From the perspective of subscribers, NGN may distinguish between user authentication and terminal equipment authentication. Network authentication is the process of verifying user/terminal equipment identifiers for transport network access only by network providers. Service authentication (including VoIP authentication) is responsible for verifying user/terminal equipment identities for service usage purpose. From the perspective of subscribers, NGN is required to provide the capability for a user to authenticate and identify a transport network provider. From the perspective of subscribers, NGN is also required to provide the capability for a user to authenticate and identify a service provider. NGN should allow for these capabilities to be independent. These distinct authentication concepts may be unified into a single concept or be applied separately, depending on the transport technology or business model. For example, a single authentication flow may be processed if a network provider is also a service provider.

General requirements for authentication capability include the following:

10

1) NGN is required to allow various network authentication mechanisms appropriate to the underlying access network technologies.

2) Service authentication should aim to be independent of the NGN access network technologies and maintain a consistent service authentication mechanism.

3) An NGN is required to request user/terminal equipment to input authentication information either in an explicit or implicit manner.

4) NGN should support both software-based and hardware-based authentication mechanisms.

5) Terminal equipment authentication that uses device profile information is required to be supported.

6) NGN should provide capabilities of bilateral authentication between service provider and user.

7) NGN should provide capabilities of bilateral authentication between transport network provider and user.

To conclude: the requirements for NGN VoIP authorization capability

include the following: 1) NGN is required to provide VoIP service access to authenticated users

and/or devices based on their access rights, user profiles and network policy. 2) VoIP service authorization should aim to be independent of the NGN

access network technologies. 3) Authorization capability should support NGN release 1 mobility scenarios

where applicable.

11

2.2. VoIP Quality of Service (QoS)

In the following chapter is described maybe one of the most important aspects of the nowadays and future VoIP NGN service, that is Quality of Service (QoS) provisioning in VoIP. At the beginning let we remind what is ITU-T ([ITU-TE.800]) and ETSI [ETSI-ETR003] basically definition of Quality of Service (QoS)?

- Qulaity of Service (QoS) is the collective effect of service performance which determines the degree of satisfaction of a user of the service.

As it is well known, to cope with the rise in traffic volume and the requirements of emerging applications (e.g., real-time, interactive, streaming) as well as the use of networks with different physical layer characteristics (e.g., wireless), comprehensive solutions have to be developed and deployed in order to transform the Internet from a commodity best-effort network to a commercial telco-grade one. The increased usage of a wide variety of wireless multimedia services is putting an ever increasing demand for high data rates on the mobile access networks, which are considered as the bottleneck link. However the time varying transmission conditions of the wireless channel and the dynamic changes of application requirements of multimedia applications make the optimization of the network resources a challenging task. Cross-Layer Optimization is an approach that addresses these issues by exchanging key parameters across the layers in order to operate the system in an optimum state.

In other words, there are also many impacts on QoS for VoIP services (which according to ITU-T is set to be in the first two QoS classes). Moreover the most essential factors are:

� Packet delay: large delays are burdensome for the user and can cause bad echos;

� Jitter: Variations in delay of packet delivery; � Packet loss: too much traffic in the network causes the network to

drop packets; � Burstiness of Loss and Jitter: Loss and Discards (due to jitter) tend to

occur in bursts. � Echoes, � and speech codec intrinsic impairments.

Depending on the utilized speech codec and compression, the required bandwidth is up to approximately 100 kbps. Note that this is low compared to video services. Apart from providing sufficient performance of the converged IP network, the choice of an adequate codec must be carefully considered to obtain satisfactory QoS for VoIP services. Standards bodies have investigated the QoS requirements relating to VoIP. The International Telecommunication Union (ITU) measured and published the so-called mean opinion score (MOS) in recommendation ITU-T P.800.1. This work showed that a satisfactory QoE

12

(Quality of Experience) for VoIP can be obtained when the network operates within QoS limits of:

- Jitter <50 ms - Delay <100 ms (or delay including jitter <150 ms, users usually notice

roundtrip voice delays of 250ms or more. ITU-T G.114 recommends a maximum of a 150 ms one-way latency. Since this includes the entire voice path, part of which may be on the public Internet, your own network should have transit latencies of considerably less than 150 ms.)

- Bandwidth: 17–106 Kbps for VoIP data plus signaling, depending on sampling rate codec, and link layer header overhead.

- Packet loss <10-2 VoIP is not tolerant of packet loss. Even 1% packet loss can "significantly

degrade" a VOIP call using a G.711 codec and other more compressing codecs can tolerate even less packet loss.

Cisco says: “The default G.729 codec requires packet loss far less than 1 percent to avoid audible errors. Ideally, there should be no packet loss for VoIP.”

As a illustration for the most network SLAs specify maxium packet loss are: - Axiowave SLA 0% maximum packet loss

- Internap SLA 0.3% maximum packet loss - Qwest SLA 0.5% maximum packet loss (in Oct 2004: 0.03%) - Verio SLA 0.1% maximum packet loss The SLA numbers above are for backbone providers, the total packet loss

for a VoIP call may also include additional packet loss in the VoIP provider's and the user's local ISP networks.

On the other hand, acceptable packet loss for VoIP services is many orders of magnitude higher than for video services, making it nearly a negligible parameter in converged IP multiplay networks.

Table 2.2. Conversational services QoS parameters.

13

It should be noted that the QoS performance targets listed above are valid for an end-to-end voice call. Since calls normally traverse many IP networks, the QoS target values must not be consumed by a single network but have to be distributed across all participating networks.

In Tables 2.2 we give more precisely QoS requirements for the real-time (conversational) services (according to IETF the services are group in three QoS gropups: Conversational, Streaming and Interactive).

Furthermore, several main mechanisms that can be used to provide quality of service for VoIP networks (and generally in all-IP networks) are proposed;

� Integrated Services (Intserv) � Differentiated Services (Diffserv) � MPLS Traffic Engineering (MPLS-TE).

Integrated Services (Intserv)

The integrated services, or Intserv, method of providing quality of service is to use a protocol for explicitly reserving bandwidth on a per flow basis. This protocol is the internet reservation protocol, or RSVP. The Intserv architecture and the application of RSVP are described in IETF RFC2210.

It is important to distinguish between RSVP itself and Intserv. RSVP is a signalling mechanism that is used to realise the intserv architecture. It is possible to use RSVP for other reasons, one example is RSVP-TE where it is used to facilitate traffic engineering for MPLS networks, and another example is aggregate RSVP that is proposed for realising dynamic Diffserv service agreements. When used as part of Intserv RSVP provides a method for a user to request a particular quality of service for a session, in effect this reserves the bandwidth throughout the network for the duration of the session. In the case of a voice session the sender of the voice flow (a SIP client) would send an RSVP path message through the network to the user (the intended receiver). Each node along the path identifies that the Path message signifies a new RSVP session and checks its resources before sending on (a possibly modified) path message. Each Intserv capable node along the path is required to store a soft state for the session and RSVP path refreshes must be sent periodically through the network to hold a particular reservation (see Figure 2.1 where the RSVP protocol is illustrated). Once the Path message reaches the user, the traffic parameters contained within the path message are checked and if the user can support such a session, or wishes to modify the session, an RSVP reservation message is sent back through the network to the sender. Since RSVP reservations are uni-directional this process would have to be carried out in two directions for a bidirectional voice circuit to be established.

Although IP networks are connectionless networks, RSVP provides a mechanism to ensure that the reservation message returns by the same route as the path messages, although this route through the network may change over the duration of a session. Each router along the RSVP “route” checks the RSVP reservation message against its available resources and determines whether it can support the reservation request. If it is able to meet the request then the

14

reservation message is sent onwards towards the sender of the data, otherwise an explict path tear message can be sent clearing the reservation.

Figure 2.1 Illustration of RSVP protocol for VoIP

Once established an Intserv session must be maintained by each router

along the path of the session. RSVP Path and Reservation messages must be sent periodically (the IETF recommends once every 30 seconds) along the path of the session (refresh messages) in order to prevent the soft state timing out in the routers. A given session persists until either it is explicitly torn down or until no refresh messages have been received within a given time period in which case the soft state in the routers times out.

Differentiated Services (Diffserv)

The Diffserv approach to providing QoS support differs fundamentally from Intserv in that it does not refer to a specific protocol for providing quality of service but rather an architectural framework designed to facilitate QoS. In Figure 2.2. the Diffserv mechanism is illustrated (compare it with the Figure 2.1). The Diffserv architecture is described in IETF RFC2474 and updated in RFC3260. Diffserv proposes that QoS should be provided by the setting and enforcing of policy within a network to provide a set of Service Level Specifications (SLS) between networks (or customers and networks), effectively service level agreements (SLA).

The key features of the Diffserv architecture are the following: � The network is divided into one or more Diffserv domains. � Sources and sinks of traffic outside of the Diffserv domain are

considered customers and would typically have an appropriate Service Level Specification that defined how much traffic and of what type they could pass into, and receive from the Diffserv domain. It is important to note that these sources may not be individual users but could be an entire network.

� The edge of the diffserv domain is made up of Diffserv boundary routers. A Diffserv boundary router performs traffic classification and

15

traffic conditioning and policing. It must provide functions for admission control, policy enforcement. In general it is the purpose of the Diffserv boundary router to maintain the integrity of the Diffserv network, to enforce service level specifications and to shape and mark traffic for transport across the remainder of the Diffserv domain.

� Unlike Intserv, Diffserv QoS functions are not applied to a single flow from a customer. Diffserv classifies traffic into a series of classes (otherwise known as per hop behaviours) and applies the same treatment to all traffic within a class.

� The core of a diffserv domain is made up of Diffserv core routers. Diffserv core routers are intended to concentrate solely on traffic handling, processing each packet based on how the packet was marked at the Diffserv Boundary. In order to facilitate QoS Diffserv core routers are likely to have a number of traffic queues available corresponding to Diffserv classes. Diffserv defines a mechanism whereby competing services and levels of traffic priority within a particular service are handled by core routers so as to guarantee the Service Level Specifications associated with each service can be met.

Figure 2.2 Illustration of Diffserv mechanism in VoIP Because Diffserv is an architecture rather than a complete solution,

supplementary elements must be added to the solution in order for it to be suitable for supporting a voice service. A key aspect of this is admission control and one way of providing it is to deploy bandwidth managers within the network. The term bandwidth manager is one that is often used but rarely well defined. Within the context of an MSF network a bandwidth manager is considered to be an entity that receives requests for bandwidth from applications, compares requests with the state of the underlying network and either accepts or rejects the requests. Of course a bandwidth manager may be made as simple or as complex as required by a network and may vary in complexity from a device that simply

16

counts sessions to one that understands the underlying network in detail and is capable of reserving and tearing down network resources dynamically.

One of the benefits of deploying a bandwidth manager is that it greatly aids network scalability because it acts as a QoS aggregation function, reserving capacity from the underlying network in bulk and then admitting individual flows to that capacity. This is important because it means the bandwidth manager can make an instant decision about a new session without consulting the many routers that will carry the traffic. However care must be taken when defining the role of a bandwidth manager not to require it to have too detailed a view of network topology or to require all bandwidth requests to be handled by a single entity. The former approach leads to duplication of topology information and the latter approach creates a bottleneck that will limit scalability.

MPLS Traffic Engineering (MPLS-TE)

MPLS traffic engineering extends the capabilities of MPLS to incorporate quality of service and as such provides a potentially useful tool to a network operator looking to support voice services. In Figure 2.3 the MPLS Diffserv packet flow is shown. MPLS can be used inside a network to setup label switched paths between ingress and egress points in the network, in effect this creates tunnels down which appropriately tagged traffic flows. By assigning a bandwidth to the label switched path on establishment it is possible to ensure that traffic being carried over a label switched path is guaranteed to be delivered to the egress point provided that the total traffic admitted to the label switched path does not exceed the bandwidth allocated to it.

Figure 2.3 Illustration of MPLS-TE process

This is a useful tool for IP networks carrying voice as it allows what

effectively is an aggregate reservation between two points down which many

17

individual flows can be carried without requiring the explicit reservation of resources for each individual flow. Furthermore this aggregate reservation can be varied with time to allow for fluctuating traffic flows in a network and when combined with MPLS fast re-routing it allows for a resilient network to be created where even significant network failures have very limited impact on the traffic being carried by a particular label switched path.

Further information about MPLS can be found in IETF RFC3031, Multiprotocol Label Switching Architecture and IETF RFC3270, Multiprotocol Label Switching Support of Differentiated Services.

Moreover, in the following the functional model and service scenarios for

QoS enabled mobile VoIP service is been described. The objective is to describe corresponding service scenarios for the case where QoS enabled mobile VoIP service is provided to the mobile users.

� QoS for mobile VoIP service

The mobile Voice over IP service is assumed to be a seamless service, i.e. a VoIP service that is implemented such that it will ensure that mobile users will not experience any service disruptions while changing the point of attachment. Mobile VoIP service requires the support of service continuity for terminal mobility taking into account network conditions (e.g. the number of user sessions, mobility events and bandwidth consumption) and users’ requirements.

QoS enabled mobile VoIP service is a mobile VoIP service which has the characteristic of ensuring the QoS when the user terminal moves, e.g. changes from one access point to another one. This service requires some form of adaptation in order to support service continuity when users’ requirements and network conditions mismatch. Adaptation may include negotiation/renegotiation of network QoS and/or terminal parameters (e.g. codec change/adaptation).

When the user terminal moves between different networks, network QoS parameters may either be maintained or adapted. Network QoS parameters include information such as IP layer available bandwidth, maximum packet transfer delay, jitter, packet loss rate, burst loss rate, packet delay variation tolerance and packet per second, etc.

In Figure 2.4 a general network architecture involving two operators supporting different types of access networks, i.e. cellular access networks (such as 3G), WiFi access networks and mobile WiMAX access networks and where users of the mobile VoIP service may move between different access networks in the same operator domain or between different operator domains is shown.

As can be seen in Figure 2.4, NGN IMS architectural components, i.e. service control functions (SCF), mobility management and control functions (MMCF), network attachment control functions (NACF) and resource and admission control functions (RACF), are assumed to be used for supporting the QoS enabled mobile VoIP service.

18

Figure 2.4 General NGN IMS network architecture for QoS enabled mobile VoIP service

In the Figure 2.5 a functional model for the support of QoS enabled mobile VoIP services is illustrated. This functional model is based on the NGN framework architecture [ITU-T Y.2012] and reuses the functions and functional entities of RACF [ITU-T Y.2111], NACF [ITU-T Y.2014], MMCF [ITU-T Y.2018] and SCF [ITU-T Y.2012].

The function model shown in Figure 2.5 includes the following functional entities:

� The functional entities in SCF for providing QoS enabled mobile VoIP service are composed of S-CSC-FE, P-CSC-FE, I-CSC-FE, SL-FE, SUP-FE, and SAA-FE. Further details can be found in [ITU-T Y.2012].

� The required functional entities in MMCF for providing QoS enabled mobile VoIP service are composed of HDC-FE, and MLM-FE. For further details see [ITU-T Y.2018].

� The required functional entities in RACF for providing QoS enabled mobile VoIP service are composed of PD-FE and TRC-FE. For further details see [ITU-T Y.2111].

� The required functional entities in NACF for providing QoS enabled mobile VoIP service are composed of TAA-FE, NAC-FE and AM-FE. For further details see [ITU-T Y.2014].

� The required functional entities in the forwarding plane for providing QoS enabled mobile VoIP service are composed of AR-FE, AN-FE, EN-FE, ABG-FE and IBG-FE. For further details see [ITU-T Y.2012]. In order to support handover execution in the forwarding

19

plane, it is assumed that L3-HEF as defined [ITU-T Y.2018] is supported by the EN-FE, ABG-FE and IBG-FE.

Figure 2.5 Functional model for QoS enabled mobile VoIP service

Based on the functional model described in this clause, in the following is

shown the overall assumptions made for describing the different service scenarios, while Appendix 1 in [ITU-T Y.2237] goes into the details of service scenarios descriptions themselves.

In the following are identified the key components assumptions considered in this functional model for QoS in mobile VoIP.

- From User terminal aspects: The user terminal (UT) is the device that facilitates end user’s access to services and applications. User terminals can be classified as single-mode terminals and multi-mode terminals.

• Single mode terminal: a terminal which provides connection to either fixed or mobile or a wireless network. Connection of a single-mode terminal to the network is identified by a single identity which is the basis to bind all services and applications

20

delivered to the terminal. A single-mode terminal is equipped with various media processing capabilities including various codecs to handle services and applications, such as voice phone call, conference, SMS, video and IPTV.

• Multi mode terminal: a terminal which provides connections to fixed, mobile or wireless networks. Each network connection of a multi-mode terminal is identified by a different identity according to each network. Therefore binding of services and applications delivered to a multi-mode terminal is much more complex than for a single-mode terminal. A multi-mode terminal is also equipped with various media processing capabilities including various codecs to handle services and applications similar to those for single-mode, but forming different set of service categories with different set of processing capabilities such as different set of codecs according to associated network connection capability.

User terminals considered in this section are multi-mode terminals, equipped with WiFi, 3G, and mobile WiMAX functions and for which different voice codecs can be associated.

- Networks aspects: The concept of generalized mobility as defined in [ITU-T Y.2001] introduces the ability to treat all related networks equally as far as mobility is concerned. This aspect raises several issues. First, the QoS capabilities may vary from one access network to another. For example, WiFi networks are able to support much higher bandwidths than mobile WiMAX or 3G networks. Second, a user terminal connected to different access networks may use different service coverage and different transmission speed. Networks considered in this Recommendation are WiFi, 3G, and mobile WiMAX networks. These networks have different capabilities owing to the different available bandwidth, service coverage, and transmission speed when a user terminal moves or accesses these different networks. The following identifies the main characteristics of these networks:

• WiFi: this network provides wireless access technology approximately 10 Mbps ~ 100 Mbps (802.11x based) transmission speed to user terminals as personal digital assistant (PDA) or notebook within several hundred meters from user terminal to access point.

• Mobile WiMAX: this network provides wireless access technology approximately 1 Mbps ~ 2 Mbps transmission speed to user terminals as personal digital assistant (PDA) or notebook with 60km/h mobility support within 100m ~ 1km service coverage per cell.

• 3G: this network provides wireless access technology approximately 10 Mbps ~ 50 Mbps transmission speed to user

21

terminals as PDA or notebook with 250 km/h mobility support within 1km ~ 3km service coverage per cell.

In this section we assumed the use of Layer 2 (e.g. MAC) authentication

based on triggering of Layer 2 signal strength in the user terminal. In addition, “make-before-break” is also assumed as a functional capability being used for handover in the transport stratum functions. The “make-before-break” functional capability minimizes packet delay and packet loss which can occur in mobile VoIP. This capability consists in pre-establishing the Layer 2/Layer 3 path before handover and releasing the previous in-service path after connecting to the pre-established Layer 2/Layer 3 path. Figure 2.6 shows handover procedure where a user terminal moves from a WiFi in-service network to a mobile WiMAX network.

Figure 2.6 Handover procedure with “make-before-break” capability

The steps considered in Figure 2.6 are as follows: (1) User terminal detects a new L2 link in the mobile WiMAX network; (2) The user terminal set-up the pre-established L2/L3 path before

handover into the mobile WiMAX network (3) The user terminal decides to handover to the WiMAX network based

on information triggers such as signal threshold or operator’s policy; (4) The user terminal communicates through the pre-established path in

the mobile WiMAX network; (5) The user terminal breaks the previous in-service path in the WiFi

network.

-Media handling aspects: The following two aspects can be considered when a user terminal moves between different networks: same quality and different quality. In the same content quality, content quality remains the same whenever the user terminal moves to between different networks. In this case, there is no need to change of media processing capability and network QoS parameters remain the same. On the other hand, in different contents quality the content quality may change when the user terminal

22

moves between different networks. In this case, there may be a need to change the media processing capabilities as well as network QoS parameters.

This section assumes that content quality can be changed when a user terminal moves between different networks and as a result, different network QoS parameters may be applied in these different networks.

- End-to-end considerations: Taking into consideration the assumptions made before, Figure 2.7 shows the overall considerations made in this section regarding user terminal, networks, and content. Figure 4 illustrates the following considerations:

• a multi-mode user terminal is operating such that its network connection is kept active as long as possible;

• the network connection of a user terminal may change depending on the user terminal behaviour such as when moving or changing the connection among WiFi, mobile WiMAX, and 3G networks. Changing of access network implies a change in the connecting capabilities like bandwidth, security, QoS, service coverage and others. Therefore, networks can be characterized by two elements: connection change and capability for different quality.

• content quality can stay the same or can change (i.e. downgrade or upgrade) depending of end-to-end QoS conditions involving the user terminal and networks. For example, when a user terminal moves from a WiFi network to mobile WiMAX network during VoIP service, the QoS enabled VoIP service may continue by QoS profile transfer from WiFi network to mobile WiMAX network.

Figure 2.7 End-to-end view of key assumptions

23

Moreover, the path between user terminal and network could pass over a variety of technologies, many of which being subject of attacks. While the network elements considered in the service scenarios described in the Appendix 1 in [ITU-T Y.2237] could be considered to be in the trusted zone, security regarding the user terminal and the path from user terminals to the network must be considered. The security requirements provided in [ITU-T Y.2701] and [ITU-T Y.2702] are applicable to the support of the QoS enabled mobile VoIP services described in this section.

24

2.3. IMS-based VoIP for NGN

In the previous section we start with IMS NGN based VoIP service in the description of the functional model for QoS enabled mobile VoIP service. This section gives more details of IMS-based VoIP for NGN and deals with a transition of VoIP to the NGN. In the same beginning of this section in Figure 2.8 is illustrated the IMS NGN architecture together with the multimedia services which IMS can provide.

Figure 2.8. IMS architecture and multimedia services

IMS standardization was started during the '90th and in that time by

"multimedia services" was meant voice with video or at the most file transfer and chat during the video/voice call. But over the time, just as the vision of multimedia services evolved, IMS evolved, too. Nowadays VoIP, IPTV, VoD and many other multimedia services rely on IMS. In Figure 2.9 the IMS releases are illustrated over the time. For more details of IMS in NGN see [ITU-T Rec. Y2211].

As a result, terms that were used in the old PSTN have to be transformed to apply to the new environment. Additionally, some terms have been ingrained over time and in some instances a number of terms have the same meaning. For readability, sometimes one term is given preference and hence is used over the others. Specifically:

• the terms "end user", "party" and "user" are used interchangeably depending on context,

• the terms "served user" and "subscriber" are used interchangeably depending on context,

25

• the PSTN/ISDN term "call" is replaced in most instances with the term "communication" when used in the context of NGN,

• in this section, when the term "real-time service" is used, it is intended that it applies to at least the voice (VoIP), video and text media types.

Figure 2.9. IMS releases As it is well known the main focus of ITU’s NGN release 1 was VoIP,

besides other real-time conversational multimedia services within an IMS-based service environment. In the following the general requirements which are required to be supported to enable IMS-based VoIP are given. Moreover this part of the section describes general objectives which would enable IMS-based real-time conversational multimedia services (at a first place: VoIP) [ITU-T Y.2201].

� NGN is required to support various media resources during sessions to enable a wide range of IMS-based real-time conversational multimedia services, including voice, video, real-time text, data, etc.

� NGNs offering IMS-based real-time conversational multimedia services are required to be able to support identical media types in both directions.

� NGNs offering IMS-based real-time conversational multimedia services are required to support the addition and removal of individual media to/from a multimedia service communication.

� NGN is required to support QoS for IMS-based real-time conversational multimedia services (including VoIP), from the point of view of users.

26

� NGN is required to allow priority for some services, e.g., emergency telecommunication, over other services.

� NGN is required to support end-to-end negotiation of codecs, to reduce the need for transcoding and thus not needlessly degrade the quality of real-time sessions.

� NGN is required to use SIP between service control functions and application/service support functions within the service stratum to support the IMS-based real-time conversational multimedia services [ITU-T Y.2012].

� NGN is required to use appropriate security mechanisms to meet the security needs of users and of the IMS-based real-time conversational multimedia services.

� NGN is required to support the use of both legacy and intelligent terminals for the provision of IMS-based real-time conversational multimedia services. Subscribers who use intelligent terminals may have access to more service features.

� NGNs are required to support flexible service trigger mechanisms to allow for creation of real-time conversational multimedia services.

� NGN is required to provide service features for IMS-based real-time conversational multimedia services that are equivalent to the services features available in legacy networks, or equivalent services.

� NGN is required to support interworking of the IMS-based real-time conversational multimedia services with the existing fixed and mobile networks, including PSTN, ISDN, GSM/UMTS, WiMAX, WLAN, LTE and Internet.

Figure 2.10. IMS-based real-time conversational multimedia services (including VoIP) functional architecture

In Figure 2.10 (above) depicts a functional architecture, based on the

NGN architecture [ITU-T Y.2012], which can be used to support IMS-based real-time conversational multimedia services, including VoIP at a first place.

27

Application support functions and service support functions contain a variety of service features for real-time conversational multimedia services. These service features may be used to implement different services in response to different requirements. Application support functions and service support functions will interact with S-CSC-FE, MRC-FE, SUP-FE and end-user functions using A-S4, A-S3, A-S6 and A-U1 respectively to deliver various service-related information.

� A-S4 is used to deliver information related to service control, including service triggering information and call control-related information. This is identified as the ISC reference point in [ITU-T Y.2021].

� A-S3 is used by application/service support functions to notify the MRC-FE of media resources control information. Moreover, A-S3 is shown within NGN environment [ITU-T Y.2012]. This is used for media resources control.

� A-S6 is used to transfer user profile information from SUP-FE to the application/service support functions, e.g., user service-related information. This is identified as the Sh reference point in [ITU-T Y.2021].

� A-U1 is used for self-management of service profiles by subscribers. This is identified as the Ut reference point in [ITU-T Y.2021].

In the following we describe service features of IMS-based VoIP service,

together with other IMS-based real-time multimedia services. A service feature is a key aspect of communication services and forms a general and primitive component to compose specific communication services. Specific communication services characterized by service features for PSTN/ISDN are out of the scope of this section and they are shown in more details in [ITU-T Rec. Y.2211]. Moreover, the following are the key service features of IMS-based VoIP service:

� Authorization code (AC): This service feature allows the served user to

override calling restrictions of the terminal from which the communication is made. Different sets of calling privileges can be assigned to different authorization codes and a given authorization code can be shared by multiple users.

� Automatic communication back (ACB): This service feature allows the called party to automatically initiate a communication back to the calling party of the most recent communication directed to the called party.

� Customized announcement (CA): This service feature allows a served user to send customized announcements during the establishment of a communication session or during an established communication session, for example, to explain the reason for rejecting a communication request, to notify of a diversion or a hold, to indicate a message waiting, or to provide a ring-back tone or media in place of a ring-back tone. The announcement may use any type of media, e.g., it may be an audio announcement, a video clip or a text message.

� Customized background music (CBM): This service feature allows playing background music during a communication, e.g., music. The

28

background music could be configured in advance by the user. The user could insert a song during a communication.

� Communication distribution (CDIST): This service feature allows the served user to specify the percentage of calls to be distributed among two or more destinations. Other criteria may also apply to the distribution of calls to each destination.

� Communication forwarding (CF): This service feature allows the called party to forward his incoming communication to another party depending on conditions specified by the called party, including busy, no reply, not logged in or unconditional. A notification of diversion may be provided to the calling party and the diverting user. As part of this service feature, when a served user attempts to initiate the call forwarding feature, the system will review the proposed "forwarded to identifier" against a disallowed forwarded to identifier database. If the identifier is found, the request to call forward to that party will be rejected (i.e., the emergency service identifier could not be set as the forwarded to identifier).

� Communication hold (HOLD): This service feature allows the user to suspend one or more media within a session, and resume that/those media at a later time. A notification may be provided to the held party.

� Communication logging (CL): This service feature allows for a communication detail record to be prepared each time a communication is received to a specified communication number.

� Customized routing (CR): This service feature enables the subscriber to accept or reject a call and, in case of acceptance, to route this call, according to a set of rules which may be based on: the calling party geographical location, the time of day, the day, and/or presence information. When this feature is applied, the service (e.g., UPT service) queries the subscriber's routing rule to obtain an appropriate terminating identifier, and routes the communication to the appropriate terminal.

� Customized ringing (CRG): This service feature allows the user to set the media provided by the media server for ringing which may be different depending on the called party, special day, etc. When the user equipment receives a communication, it detects whether the ringing is networked or local. If the ringing is networked, the user equipment activates the service by initiating a request to connect to the media server and then the user equipment plays the media stream received from the media server. The customized ringing media could be a specific song, an image, or a multimedia stream.

� Communication transfer (CT): This service feature enables a user to transfer an established (i.e., active) communication to a third party.

� Click-to-dial (CTD): This service feature allows the user to initiate a request to establish a communication conveniently by clicking on a web page icon or button. The use of this service feature alone is not sufficient to establish a communication, this service feature needs to combine with the third party communication control service feature.

29

� Communication waiting (CW): This service feature allows the called party to receive a notification that another party is trying to reach his number while he is busy communicating to another party.

� Destination-associated message type query (DMTQ): This service feature allows the user to pre-define possible message types, with this information being accessible by other users. When this feature is applied, the user is able to access this information by querying the application server to obtain a destination terminal address and the associated pre-defined message types.

� Follow-me diversion (FMD): With this service feature, a user may register for incoming calls to any terminal access. When registered to a terminal access, all incoming calls to the user will be presented to that terminal access. A registration for incoming calls will cancel any previous registration. Several users may register for incoming calls to the same terminal access simultaneously. The user may also explicitly de-register for incoming calls.

� Group communication (GC): This service feature allows the user to request pre-defined group information stored in the network when establishing multiple simultaneous communication with other parties. The use of this service feature alone is not sufficient to establish the communication. Different users are added to the communication according to their pre-defined privileges.

� Multi-party communication (MPC): This service feature allows the user to establish multiple simultaneous communication with other parties.

� Message waiting (MW): This service feature enables a user to be informed that messages for his attention are waiting.

� Originating communication screening (OCS): This service feature allows the subscriber to specify that outgoing calls be either restricted or allowed, according to a screening list and, optionally, by time of day control. This can be overridden on a per-communication basis by anyone with the proper authorization code.

� Off-line charging (OFLC): This service feature allows for off-line charging for services where delayed charging is acceptable.

� ON-line charging (ONLC): This service feature allows applying on-line charging for services where real-time charging and control are critical and required.

� Personal identifier (PI): This service feature allows the user to hold a unique identifier as personal identification while communicating with others. The user can use a personal identifier as his/her unique identification to communicate with others. All of the user's terminal devices could be bound with a personal identifier. The service capabilities would be defined with respect to a personal identifier. No matter whether a binding fixed terminal or a binding mobile terminal is used, the user could enjoy the same service experience.

30

� Reverse charging (REVC): This service feature allows the service subscriber (e.g., free phone) to accept receipt of calls at its expense and be charged for the entire cost of the communication.

� Ring pattern (RP): This service feature supports various ring patterns of destination number, i.e., parallel ring, sequential ring, combination ring of the previous two.

� Split charging (SC): This service feature allows for the separation of charges for a specific communication, the calling and called party each being charged for one part of the communication.

� Terminating communication screening (TCS): Terminating calls may be controlled by the terminating communication screening capability. This allows the called party to specify that incoming calls be either restricted or allowed, according to a screening list of identifiers of the calling parties and, optionally, by time of day control.

Typical scenarios include: 1) Calling user A attempts to make a communication to B. The communication is screened via the screening list assigned to B. The communication is allowed to complete and A is connected to B. 2) Calling user A attempts to make a communication to B. The communication is screened via the screening list assigned to B. The communication is not allowed to complete and A is connected to an announcement.

� Third party communication control (3PCC): This service feature allows a user to set up, release and control a communication between parties when the user is different from the parties directly involved in the communication.

� Unsuccessful communication notification (UCN): This service feature allows the subscriber to be informed of the unsuccessful incoming calls in a preset way, e.g., e-mail message, etc.

� User identification presentation and restriction (UIPR): This service feature allows the user to receive user identification information from the other party or prevent presentation of his user identification information to the other party within a communication. The user could be either a calling party or a called party. As government policy or operator policy, this feature is sometimes forced to be supported.

� User profile management (UPM): This service feature allows the served user to manage his service profile, e.g., terminating destinations, announcements to be played, communication forwarding, and so on. Moreover, just to emphasize that the IMS NGN supports the

interoperability of the PSTN/ISDN simulation services with PSTN/ISDN services and vice versa. This includes interworking PSTN/ISDN supplementary services with the services defined in [ITU-T Rec. Y2211] and vice versa. However, the scope of this interworking may result in a limited service capability.

31

2.4. VoIP over wireless and mobile networks

Fact is that VoIP has rapidly become popular in wireless and mobile

networks. Wireless and mobile networks are having substantial impact on VoIP service development (particularly in developing countries). As wireless and mobile VoIP traffic increase, differences in the terms and conditions under which wireless/mobile and VoIP operators interconnect networks will create opportunities for arbitrage, and distort markets. Differences in call termination rates and interconnection arrangements can cause operators to adjust traffic flows to obtain the lowest possible rate, and to minimize regulatory fees.

Incumbent operators may seek to exploit “bottlenecks” and essential facilities, by imposing above cost termination charges to deliver calls to wireless and mobile subscribers, or to deliver wireless and mobile traffic to wireless/mobile subscribers. This may encourage wireless carriers and VoIP providers to avoid the incumbent’s network by seeking cheaper alternatives for originating and terminating traffic.

Although VoIP has become very popular and successful in wireless and mobile networks - many technical challenges remain. Listed below are some of the major challenges that exist:

� Delay and jitter control. In wireline systems, channels are typically clean and end-to-end transmission can be almost error-free, requiring no retransmissions. However, a wireless channel could be unfavorable, resulting in bit errors and corrupted packets. Packets may have to be retransmitted multiple times to ensure successful reception, and the number of retransmissions depends on the dynamic radio frequency (RF) conditions. This could introduce significant delay and delay variations. Further, unlike the circuit channels, which have a dedicated fixed bandwidth for continuous transmission, packet transmissions are typically bursty and share a common channel that allows multiplexing for efficient channel utilization. This operation also results in loading-dependent delay and jitter.

� Spectral efficiency. In a wireline VoIP system, bandwidth is abundant, and it is often used to trade-off a shorter delay. In fact, more bandwidth-efficient circuit-switched transmissions have been abandoned in favor of the flexibility of packet-switched transmissions, even though packet transmissions incur extra overheads. In wireless systems, however, the spectrum resource is generally regarded as the most expensive resource in the network, and high-spectral efficiency is vitally important for service providers. Therefore, wireless VoIP systems must be designed such that they can control delay and jitter without sacrificing spectral efficiency.

32

Packet transmission overheads must also be kept to a minimum over the air interface.

� Mobility management. In many wireless and mobile systems, mobility management has been designed mainly for data applications. When mobile users move among cell sites, the handoff procedure follows the break-before-make principle. This leads to a large transmission gap when the mobile is being handed off from one cell site to another. While a transmission gap is often acceptable in data applications, it is unacceptable for voice. To support VoIP applications, the handoff design must be optimized so that the transmission gap during the handoff is minimized and does not impact voice continuity.

� Transmission power and coverage optimization. With the packet overheads, a higher power is needed to transmit the same amount of voice information, which results in smaller coverage. In addition, bursty packet transmissions also cause a higher peak-to-average transmission power ratio, which in turn may lead to a higher power requirement in the short term and degraded performance in the outer reaches of the areas covered by the network. Therefore, more advanced techniques must be adopted to compensate for these shortcomings.

In the following the VoIP over the most popular wireless and mobile networks, such: WiMAX, WLAN and 3G/LTE/LTE-Advanced is discussed.

2.4.1 VoWiMAX

Since VoIP provides an alternative to the telephone service offered by the

traditional PSTN by using an IP network to carry digitized voice, the packet switched air interfaces that support flat IP architectures have now made it possible to run VoIP service over wireless technology.

Compression/Decompression (CODEC) techniques for VoIP transform audio signals into digital bit streams. While preserving voice quality, speech samples are further compressed to produce bit streams of 8–12 kbps that are carried over the IP network. The compressed speech sample is then transmitted using the Real-time Transport Protocol (RTP) over the User Datagram Protocol (UDP) over the Internet Protocol (IP). Moreover, the VoIP over wireless networks is affected by the choice of CODEC and packet loss, delay and jitter. Fluctuating channel conditions typically cause packet loss and increased latency. In order to keep mouth-to-ear round trip latencies to reasonable levels of 250–300 ms, the delay budget for transmission over the air interface is 50–80 ms. The CODEC, jitter buffer and backbone account for the remaining delay. Channel aware scheduling with Quality of Service (QoS) differentiation, Hybrid Automatic Repeat Request (HARQ) and dynamic link adaptation are used to keep delays within acceptable limits. Jitter buffers are used to compensate for delay jitter experienced by packets due to network congestion, timing drift or route changes.

33

This part of the chapter 2.4 provides an overview of VoIP over WiMAX (VoWiMAX). It includes a detailed description of essential and advanced mobile WiMAX features that support VoIP.

WiMAX provides a number of features to support VoIP. Prioritization of delay-sensitive VoIP traffic is achieved through the classification of flows into scheduling classes. Voice activity detection and Extended Real-Time Polling Service (ertPS) conserve air link resources during periods of silence. HARQ and channel aware scheduling are used reduce transmission latency over the air link. Protocol header compression is supported to transport the speech sample efficiently.

- Silence Suppression using ertPS Mobile WiMAX supports QoS requirements for a wide range of data

services and applications by mapping those requirements to unidirectional service flows that are carried over Uplink (UL) or Downlink (DL) connections. Table 2.3 describes the five QoS classes, Unsolicited Grant Service (UGS), Real-Time Polling Service (rtPS), ertPS, Non-Real-Time Polling Service (nrtPS) and Best Effort (BE) service, used to provide service differentiation by the Medium Access Control (MAC) scheduler.

Table 2.3. WiMAX QoS classes _____________________________________________________

In the absence of silence suppression, service requirements for VoIP

flows are ideally served by the UGS, which is designed to support flows that

34

generate fixed size data packets on a periodic basis. The fixed grant size and period are negotiated during the initialization process of the voice session.

Service flows such as VoIP with silence suppression generate larger data packets when a voice flow is active and smaller packets during periods of silence. The rtPS is designed to support real-time service flows that generate variable size data packets on a periodic basis. The rtPS requires more request overhead than UGS, but supports variable grant sizes. In conventional rtPS, a bandwidth request header is sent in a unicast request opportunity to allow the Subscriber Station (SS) to specify the size of the desired grant. The desired grant is then allocated in the next UL subframe.

Although the polling mechanism of rtPS facilitates variable sized grants, using rtPS to switch between VoIP packet sizes when the SS switches between the talk and silent states introduces access delay. rtPS also results in MAC overhead during a talk spurt since the size of the VoIP packet is too large to be accommodated in the polling opportunity, which only accommodates a bandwidth request header. The delay between the bandwidth request and subsequent bandwidth allocation with rtPS could violate the stringent delay constraints of a VoIP flow. rtPS also incurs a significant overhead from frequent unicast polling that is unnecessary during a talk spurt.

The ertPS scheduling algorithm (see Figure 2.11) improves upon the rtPS scheduling algorithm by dynamically decreasing the size of the allocation using a grant management sub-header or increasing the size of the allocation using a bandwidth request header. The size of the required resource is signalled by the Mobile Station by changing the Most Significant Bit (MSB) in the transmitted data.

Figure 2.11. Illustration of ertPS scheduling algorithm - HARQ In addition to link adaptation through channel quality feedback and

adaptive modulation and coding, HARQ is enabled in 802.16e using the „stop

and wait� protocol, to provide a fast response to packet errors at the Physical

35

(PHY) layer. Chase combining HARQ is implemented to improve the reliability of a retransmission when a Packet Data Unit (PDU) error is detected. A dedicated Acknowledgment (ACK) channel is also provided in the uplink for HARQ ACK/Negative Acknowledgment (NACK) signalling. UL ACK/NACK messages are piggybacked on DL data. A multi-channel HARQ operation with a small number of channels is enabled to improve the efficiency of error recovery with HARQ. Mobile WiMAX also provides signalling to allow asynchronous HARQ operation for robust link adaptation in mobile environments.

The one-way delay budget for VoIP on the DL or the UL is limited between 50 and 80 ms. This includes queuing and retransmission delay. Enabling HARQ retransmissions for error recovery significantly improves the ability of the system to meet the stringent delay budget requirements and outage criteria for VoIP.

Hybrid automatic repeat request (Hybrid ARQ or HARQ) is a combination of forward error-correcting coding and error detection using the ARQ error-control method. In standard ARQ, redundant bits are added to data to be transmitted using an error-detecting code such as cyclic redundancy check (CRC). In Hybrid ARQ, forward error correction (FEC) bits are added to the existing Error Detection (ED) bits to correct a subset of all errors while relying on ARQ to detect uncorrectable errors. As a result Hybrid ARQ performs better than ordinary ARQ in poor signal conditions, but in its simplest form this comes at the expense of significantly lower throughput in good signal conditions. There is typically a signal quality cross-over point below which simple Hybrid ARQ is better, and above which basic ARQ is better.

- Channel Aware Scheduling Unidirectional connections are established between the BS and the MS to

control transmission ordering and scheduling on the mobile WiMAX air interface. Each connection is identified by a unique Connection Identification (CID) number. Every MS, when joining a network, sets up a basic connection, a primary management connection and a secondary management connection. Once all of the management connections are established, transport connections are set up. Traffic allocations on the DL and the UL are connection based, and a particular MS may be associated with more than one connection.

In every sector, the Base Station (BS) dynamically schedules resources in every Orthogonal Frequency Division Multiple Access (OFDMA) frame on the UL and the DL in response to traffic dynamics and time-varying channel conditions. Link adaptation is enabled through channel quality feedback, adaptive modulation and coding and HARQ. Resource allocation on the DL and UL in every OFDMA frame is communicated in Mobile Application Part (MAP) messages at the beginning of each frame. The DL-MAP is a MAC layer message, which is used to allocate radio resources to Mobile Stations (MS) for DL traffic. Similarly, the UL-MAP is a MAC layer message used to allocate radio resources to the MS for UL traffic. The BS uses information elements within the DL-MAP and UL-MAP to signal traffic allocations to the MS.

36

The BS scheduler also supports resource allocation in multiple subchannelization schemes to balance delay and throughput requirements with instantaneous channel conditions.

- Security Securing the voice communication is also a big challenge for VoIP over

WiMAX as care has to be taken that it cannot be eavesdropped or intercepted. The Double encryption process - X.509 for Authentication and 152-bit AES, 3DES or 56-bit DES for data flow ensure the transmission is secure and eavesdropping is very difficult on the traffic. When a Subscriber Station (SS) needs to associate with a Base Station (BS), it sends an authorization request along with authentication information in a X.509 certificate.

The BS after verifying the certificate responds by sending the authorization message which has the authorization key encrypted with subscriber's public key, to enable the subscriber to register with the network. An IP address is given to the SS by the DHCP. The DHCP server also provides the address of the TFTP server, from where the SS gets the vendor specific configuration information file.

After this, the BS accepts the subscriber. The data stream is further encrypted using 56-bit DES, 3DES or 152-bit AES. This prevents the possibility of eavesdropping on the data and theft of service as the links between the BS and SS are encrypted. Also WiMAX has built in virtual LAN (VLAN) support which provides protection for data transmitted by multiple users on the same BS.

*Note: In cryptography, X.509 is an ITU-T standard for a public key infrastructure (PKI) for single sign-on (SSO) and Privilege Management Infrastructure (PMI). X.509 specifies, amongst other things, standard formats for public key certificates, certificate revocation lists, attribute certificates, and a certification path validation algorithm. In the X.509 system, a certification authority issues a certificate binding a public key to a particular distinguished name in the X.500 tradition, or to an alternative name such as an e-mail address or a DNS-entry. X.509 also includes standards for certificate revocation list (CRL) implementations, an often neglected aspect of PKI systems. The IETF-approved way of checking a certificate's validity is the Online Certificate Status Protocol (OCSP). Firefox 3 enables OCSP checking by default along with versions of Windows including Vista and later.

� Enhanced Features for Improved VoIP Capacity

There are several characteristics of VoIP traffic that make VoIP packet

scheduling challenging: � VoIP packets are small in size. � Number of VoIP users supported in a given frequency band is

large compared with the number of high data rate users that can be supported.

� The packet inter-arrival time is roughly constant. � Speech includes periods of silence for roughly half the time and

activity during the rest of the time.

37

The fact that the VoIP packet size is small makes the ratio of the resources needed for transmitting control information to schedule VoIP to the resources needed for actual VoIP traffic transmission much higher than that observed in data-only systems. Moreover, the high number of VoIP users supported in a given frequency band also adds to the total overhead required to transmit the control information related to the VoIP resource allocation.

In supporting high data rate applications, the focus is on optimizing the throughput, but in supporting VoIP the focus shifts towards delay sensitivity and minimizing the control overhead associated with the VoIP resource allocation.

- Dynamic Resource Allocation for VoIP To support VoIP in an OFDMA system, VoIP packets need to be

scheduled on the DL and the UL within a fixed delay bound every time a packet arrives at the BS and at the MS, respectively. The OFDMA resources in frequency and time as well as transmit power and transmission mode need to be specified in each allocation. Furthermore, the MS identification and HARQ transmission related information also need to be specified.

All this information is sent using a robust Modulation and Coding Scheme (MCS), thereby consuming additional resources. In WiMAX, control information associated with resource allocation is signalled through MAP elements. Compressed MAPs can be used with subMAPs to reduce MAP overhead. The compressed MAP header is coded with the most robust MCS and subMAPs can be coded with higher order MCSs. Although compressed MAPs and subMAPs conserve resources compared to conventional MAPs, MAP overhead associated with the larger number of allocations for VoIP can be considerably high.

Dynamic scheduling for every VoIP packet incurs a significant amount of MAP overhead. The motivation for persistent scheduling comes from the fact that the VoIP traffic is periodic and generates constant size packets. As the name suggests, persistent scheduling conserves resources by persistently allocating resources that are required periodically. We discuss two different ways of persistently allocating the resources, namely individual persistent scheduling and group scheduling.

- Individual Persistent Scheduling The basic idea behind individual persistent scheduling is that a user is

assigned a set of resources for a period of time and the necessary information for the packet transmission are sent only once at the beginning of the assignment. For the rest of the period of allocation, the MS is assumed to know all of the information for data reception on the DL and data transmission on the UL. Note that the allocation period can be infinite. In other words, persistent scheduling is in effect until updated.

Figure 2.12 compares the operation of dynamic and persistent scheduling operation. In the case of dynamic scheduling, a MAP element is required to specify resource allocation information every time a VoIP packet is scheduled. On the other hand, in the case of persistent scheduling, resource allocation information is sent once in a persistent MAP element and not repeated in the

38

subsequent frames. The additional resource that becomes available due to MAP overhead reduction can be used to increase VoIP capacity.

Figure 2.12. Dynamic vs persistent scheduling operation

- Resource allocation/deallocation for talk spurts/silence periods As discussed earlier, VoIP users switch between talk spurts and silence.

On the average, users in a typical VoIP call will be in either mode for duration of the order of a second. Every time a user goes into a talk spurt, resources need to be allocated with all of the information necessary to identify the allocation. The resource is allocated periodically with persistent scheduling as long as the user is in the active state. Similarly, every time the user goes into the silence mode, resources need to be deallocated. Since the frequency of allocation and deallocation of resource for conversational voice (50% voice activity factor) is typically once every 250 WiMAX frames (1.25 s), the overhead associated with a persistently scheduled allocation is small compared with the overhead in dynamic scheduling.

- Link Adaptation/MCS Changes In a mobile environment, the channel conditions are time varying. In order

to be spectrally efficient, the MCS used for data transmission and reception needs to be adapted according to channel variations. Adjustment in MCS requires changes in the amount of allocated resources. As a result, every time the MCS needs to be adapted, the BS needs to deallocate or allocate a persistently scheduled resource. Depending on the frequency at which the MCS changes, signalling the changing persistent allocation could result in considerable overhead. Consequently, for fast link adaptation, individual persistent scheduling is not recommended, since the overhead involved in adapting to the channel variations will defeat the purpose of persistent scheduling.

2.4.2 VoWLAN

There exist two major challenges for VoIP over WLAN (VoWLAN). One

challenge is how to increase the system capacity for voice users. Originally designed for data traffic, the WLANs experience bandwidth inefficiency when supporting voice traffic due to the large overhead. Hence, it is essential to enlarge the VoIP capacity supported by WLANs. The other challenge is quality of service (QoS) provisioning for voice users. Voice traffic is sensitive to delay and

39

delay jitter. In current WLANs, VoIP traffic may be interfered by other traffic (e.g., data traffic), resulting in a delay bound violation or large delay variance. Therefore, it is necessary to enhance QoS support capability over WLANs.

Moreover, let we start with the first challenge – capacity for VoIP: when designing a VoWLAN system, it’s one of the most important issues - to determine the network voice capacity, in terms of the maximum number of simultaneous voice connections that can be supported in an IEEE 802.11 WLAN, especially for the prominently deployed DCF-based WLANs even if the transmission rate of mobile stations goes into infinite. Thus, reducing overhead is vital. In the literature, many existing throughput and delay analyses are based on the model that the active mobile stations are saturated, i.e. they always have data to transmit.

However, the saturated station model is not suitable for voice traffic, which is usually considered as a constant bit rate traffic, or as a variable bit rate traffic if considering the alternating periods of talk spurts and silence. Voice capacity of WLANs has been actively investigated via experiments and analytical models. It shows that the 802.11b can support ten voice connections using voice codec G.711, a 10ms packetization interval, and silence suppression. A measurement experiment with the voice codec G.711 without silence suppression has been carried out and it is proven that only six VoIP connections can be accommodated in an 802.11b WLAN.

The different measurement results show that the silence suppression and packetization interval play an important role on WLAN voice capacity. On the other hand, many analytical models have been proposed in order to evaluate the voice capacity of infrastructure, DCF-based WLANs. The analytical results quantify how the system parameters affect the WLAN voice capacity. There is an analytical model which considered the header overhead of each layer (e.g. RTP, UDP, IP, MAC and physical layer headers) and the overhead introduced by the MAC protocol, including DIFS, SIFS, ACK, and the random backoff, and simplified the analysis with the assumptions that there are no collisions and all mobile stations take advantage of the backoff time of the AP to fulfil their own backoff requirements.

Since all traffic to and from the WLAN has to go through the AP (in CSMA/CA), the traffic arrival rate of the AP is the summation of that of all mobile stations. When more voice connections join in the network, the service rates of the AP and mobile stations decrease non-linearly because more collisions may occur. A station is considered unstable when its traffic arrival rate is larger than the frame service rate, and the queue of the station will build up, and thus the voice connection will suffer from excessive delay and packet losses due to buffer overflows. It is pointed out that when the number of voice connections approaches the voice capacity, one more VoIP connection may cause the AP to be unstable, and thus jeopardize the performance of all downlink voice traffic.

Moreover, some analytical results of the voice capacity with different codecs and packetization intervals are compared in Table 2.4.

40

Table 2.4. Comparison of the maximum number of VoIP connections for 802.11b.

Different from the above mentioned models using a CBR voice traffic model, an On–Off traffic model, as specified in the ITU P.59, was used in order to analyse the network capacity of 802.11a/b/g WLANs, as shown in Figure 2.13.

The conversation between two users A and B is modelled as a four-state Markov chain, including (a) A talking B silent, (b) A silent B talking, (c) both talking and (d) both silent; the durations of states are mutually independent and identically distributed (i.i.d.) exponential random variables with means of 854, 854, 226 and 456 ms, respectively. It is obtained that 22 and 102 G.711 connections can be accommodated in an 802.11b and 802.11a WLAN, respectively. In other words, considering the silence intervals in a voice conversation, the voice capacity almost doubles compared to the results with a CBR traffic model.

Figure 2.13. Conversational speech modelled as four-state Markov chain

Long story in short: for 802.11b WLANs with very limited capacity, since

all on-going voice traffic will be jeopardized if the AP becomes unstable, it is suggested to use a tight bound (the voice capacity obtained with the CBR traffic model) to limit the number of voice connections conservatively; on the other hand, when a WLAN can support a large number of voice connections, e.g. an

41

802.11g WLAN, the On–Off traffic model can be used to fully explore the multiplexing gain. In addition, the experimental and analytical results reveal that the voice capacity is a function of the system parameters, including transmission rate, voice packet payload length (dependent on the codec used), and packetization interval. Since the transmission rate is bounded according to the 802.11 standards, two feasible ways to increase the voice capacity are:

1) either to enlarge the packetization interval 2) or to choose an efficient voice codec. Due to the large overheads at the MAC and physical layers, voice capacity

is affected more by the packetization interval than by the payload length of voice packets. On the other hand, larger packetization interval brings more end-to-end delay, which may degrade the voice quality. There is a trade-off between the delay constraint and the voice capacity.

On the other hand we have a connection admission control (CAC) in WLAN, which is mechanism implemented to decide whether or not a new connection (VoIP call, data, video connectons) should be admitted into, and supported by, the system. Many analysis and results have shown that placing an additional voice that exceeds the capacity of the WLAN will result in unacceptable quality for all ongoing VoIP connections. Therefore, admission control is necessary to maintain the quality for VoWLANs. For infrastructure-based WLANs, admission control can be implemented at the AP, which can block traffic from any new connections when the current traffic load reaches the network capacity. If the WLAN supports voice traffic only, the voice capacity previously obtained can be applied directly for admission control. However, when the WLAN supports heterogeneous voice and data traffic, how to determine the appropriate admission region to efficiently utilize network resources and guarantee the voice quality is still an open issue.

Furthermore, the second challenge in VoWLAN is QoS. VoIP QoS is closely related to three factors: packet end-to-end delay, delay jitter (delay variation), and packet loss. A two-way conversation is very sensitive to delay and delay jitter, but it can tolerate some degree of packet losses, depending on the error-resilience of the codec used.

As we mention in section 2.2 - ITU has recommended that one-way end-to-end delay should be no greater than 150 ms for good voice quality, and up to 400 ms for acceptable voice quality, with an echo canceller. The delay constraint is much more stringent when no echo canceller is adopted, and the end-toend delay should be limited to 25 ms for acceptable quality. For VoWLAN applications, delay includes codec delay, packetization delay, and network delay in both the WLAN and the backbone networks.

Delay jitter, or delay variation, mainly due to network dynamics, has even more negative effects on voice quality than that of delay. Since the WLAN is presumably the bottleneck, delay jitter in the WLAN is the dominant part. With the CBR traffic model for voice, delay jitter is mainly due to the random channel service time, the time duration the network interface has taken to successfully transmit a frame over the WLAN, which is determined by the MAC protocol and the data transmission rate. Delay jitter can be removed by adopting a small

42

playout buffer at the receiver with an efficient playout algorithm [20]. Packets arriving at the receiver later than the playout time will be discarded. The playout buffer size should be carefully chosen; large playout buffer size may introduce additional delay, and small buffer size may result in considerable packet losses.

Packet loss is also a major source of impairment in VoIP systems. According to 2.2, a voice quality is considered acceptable only when the packet loss rate is less than 1-2%. There are two sources of packet losses: (1) network packet losses, mainly due to network congestion (router buffer overflow), link failures and rerouting, transmission errors, etc.; and (2) discarded packet losses for packets experienced excessive delay.

To support both voice and data applications over WLANs, it is important to design a MAC protocol with QoS support to voice traffic, implement an appropriate queue management scheme, develop efficient playout buffer algorithms, and increase the transmission rate with a more efficient physical layer protocol, etc. The playout buffer algorithms and physical layer design are out of the range of this paper. Here, we mainly focus on the QoS enhancement mechanisms in the MAC layer.

Whether the IEEE 802.11 MAC can provide desired QoS for voice connections has been extensively investigated. With the legacy 802.11 DCF mode, all stations, including the AP if available, compete for channel access with the same priority. There is no mechanism to assign higher priority to real-time traffic with stringent QoS requirements.

In the MAC layer, two main approaches have been proposed to better support real-time applications: the polling-based mechanism and the prioritized contention-based mechanism.

The optional PCF mode is available in a centrally controlled WLAN, using a polling-based mechanism intended to guarantee delay for real-time applications. And on the other hand, service differentiation schemes have been proposed to provide better QoS for multimedia applications in IEEE 802.11 WLANs. Service differentiation can be achieved using priority queue management schemes and/or using different MAC parameters for different classes of traffic. With priority queue schemes, traffic is classified into different priorities and each class of traffic occupies a separate queue. Within a station, packets buffered in a higher priority queue will be served earlier than those in a lower priority queue.

On the basis of differentiated schemes, the IEEE 802.11e standard, an enhancement of the legacy 802.11, is proposed to offer QoS provisioning for multimedia applications (including VoIP - with high priority). First, the enhanced DCF (EDCF) is an extension of DCF with four levels of statistical access priority, enabling different traffic categories to be served in different priority queues. The contention-based channel access function of IEEE 802.11e, EDCF, adopts eight different priorities, which are further mapped into four access categories (see the four AC on Figure 2.14). Access categories are achieved by differentiating the arbitration inter-frame space (AIFS), the initial contention window size, and the maximum window size.

43

Figure 2.14. 802.11e Mapping of different priorities in 4 ACs.

With a smaller AIFS or window sizes, the higher priority class of traffic has

a better chance to access the wireless medium. Although different priorities are implemented in EDCF, access to the medium is still determined according to the basic CSMA/CA mechanism. Therefore, EDCF is a prioritized contention-based mechanism.

Second, an extension of the PCF option called the hybrid co-ordination function (HCF) is proposed, which negotiates connections between an AP and the mobile stations, along with specifically assigned transmission durations for each frame. HCF also implements priority queue for different traffic categories so that voice traffic always has the highest priority than other traffic. Therefore, HCF is a hybrid of prioritized contention-based and polling-based mechanism for QoS provisioning. Unlike PCF, there is no specific boundary between the CP and CFP in 802.11e. The hybrid co-ordinator (HC) can poll any mobile station on the polling list in both CFP and CP, whereas the PC can only poll stations in CFP.

Third, the direct link protocol (DLC) permits two stations to communicate directly in the infrastructure-based WLAN, which significantly improve the network performance. Fourth, the group ACK mechanism, in which the receiver sends one ACK for a number of data packets received, can also reduce some overhead. These new features of 802.11e can definitely improve the performance of voice traffic in a WLAN. However, there are still some concerns

44

about the QoS guarantees that the protocol aims to provide. EDCF is a prioritized contention-based mechanism and cannot guarantee that low-priority packets will always wait until all packets with higher priority are transmitted. HCF suffers from the same complexity-efficiency trade-off in polling schemes as PCF does. Due to the complicated QoS provisioning mechanism specified in the protocol, it is very difficult to analyse the network performance of the 802.11e and to find the optimal parameters to achieve the best performance.

2.4.3 VoIP over 3G/LTE/LTE-Advanced

Driven by the success of mobile broadband, LTE is now rapidly gaining

momentum in the market. VoIP over LTE is a step towards future telephony. Mobile broadband gives operators new revenue and many business opportunities. However, it also challenges the operators’s current SMS and voice revenues, which today represent more than 70 % of their global business. So a key question is how to take advantage of the mobile broadband opportunities while maintaining and growing current revenue from traditional communication services (with more attractive service packages). LTE is set to play a key role in these efforts, since this new technology brings higher capacities and lower latencies, resulting in an improved user experience for all kinds of services. This, in turn, puts pressure on telecom operators to come up with a global voice and messaging solution for LTE, providing a communication service package that can be evolved to support the rich multimedia experience that consumers demand.

Moreover, let we see what is the solution for voice over LTE that is both advantageous for operators and satisfies user expectations and what steps need to be taken to deploy such a solution.

In the new LTE Radio and Evolved Packet Core (EPC) architecture, there is no circuit-switched domain to handle voice calls in the traditional 2G/3G way. A solution for voice over LTE will, therefore, be needed as LTE access becomes more widespread. Over the past years, the industry has identified four main tracks:

� Circuit Switched Fallback (CSFB) to 2G/3G CS – for example, 3rd Generation Partnership Project (3GPP) CSFB

� IMS-based, such as 3GPP IP Multimedia Subsystem (IMS) Multimedia Telephony (MMTel) over LTE

� Over-the-top (OTT) – for example, Skype � Circuit Switched over Packet Switched (CS over PS) – for example,

voice over LTE via Generic Access (VoLGA) The first and last tracks, CSFB and CS over PS, are interim solutions for

early LTE deployment stages. The OTT-based and MMTEL-based tracks can be viewed as more permanent solutions for mature LTE networks.

� Circuit Switched Fallback

CSFB is the 3GPP standard solution for early LTE deployment stages, where no IMS voice service is available. Through CSFB, the terminal is directed to WCDMA/GSM to initiate or take a voice call, and the call remains in the CS

45

domain until it is completed. This solution is currently recommended by the Next Generation Mobile Networks (NGMN) Alliance as a minimum roaming requirement for LTE terminal vendors and LTE operators that provide a CS voice service over WCDMA/GSM. As CSFB only provides support for voice and SMS, it is considered an intermediate step in the evolution towards fully fledged multimedia communication services.

� MMTel-based

The 3GPP MMTel solution gives operators the possibility to evolve their telephony service by incorporating the multimedia feature-richness needed to compete with OTTs. Additionally, MMTel can leverage the world’s biggest mobile user community – Mobile Subscriber Integrated Services Digital Network number (MSISDN) – as well as classical telecommunication values, such as:

� High-quality, guaranteed end-to-end QoS � Regulatory services support (such as emergency calls) � Global reach.

� OTT

OTT solutions, such as Skype and Google Talk, are being pre-installed in high-end phones. As mobile barriers for OTT players are gradually disappearing and smartphone penetration is expected to flourish over the next few years, OTT solutions will probably drive competition in the mobile domain as we saw in the fixed domain. However, because OTT solutions cannot provide a satisfactory user experience in non-continuous LTE coverage (due to the lack of a handover mechanism to the CS network), the adoption of OTT clients will depend on mobile broadband coverage. Therefore, if operators react soon, it should be possible to consolidate a global voice over LTE solution even before the LTE coverage is fully deployed.

� CS over PS VoLGA, specified by the VoLGA Forum, is perhaps the best-known

alternative in the CS over PS family. The main idea is to adapt Universal Mobile Access / Generic Access Network (UMA/GAN) for LTE, and reuse the 3GPP Single Radio Voice Call Continuity (SRVCC) mechanism for handover from LTE to 2G/3G CS. It has very low impact on the existing CS core, but does not offer the possibility of evolving toward a full multimedia service experience. Therefore, VoLGA has been positioned as an interim alternative that addresses pre-IMS LTE deployments. However, the VoLGA solution is not standardized by 3GPP, and after GSMA adopted the One Voice initiative for GSMA VoLTE, VoLGA has been constantly loosing traction in the industry.

From the above possibilities, the MMTel-based alternative has been

chosen by GSMA as the unified solution for voice – and SMS – over LTE, termed GSMA VoLTE, and has wide backing in the industry with more than 40 key players declaring their support at the 2010 GSMA Mobile World Congress. GSMA VoLTE will not only bring unified profiling for the deployment of an

46

interoperable, highquality voice and SMS service over LTE, but will also facilitate the development of interconnect and international roaming agreements among LTE operators. Furthermore, the global GSMA collaboration widens industry support and brings economy of scale for both terminals and network infrastruture, as required for mass-market uptake. With GSMA VoLTE, a solution based on well established standards and supported by the entire industry, operators can easily evolve their voice services toward a rich multimedia offering to both protect and grow their communication business. At the same time, users will benefit from richer multimedia services, available anywhere on any device, combining mobility with service continuity to provide users with the high-quality experience they expect.

Moreover the voice over LTE solution is defined in the GSMA Permanent Reference Document (PRD) IR.92, based on the adopted One Voice profile (v 1.1.0) from the One Voice Industry Initiative. VoIP over LTE is therefore based on the existing 3GPP IMS MMTel standards for voice and SMS over LTE, specifying the minimum requirements to be fulfilled by network operators and terminal vendors in order to provide a high quality and interoperable voice over LTE service. Furthermore, the basic scenario (see Figure 2.15) in the VoIP over LTE profile assumes full LTE coverage or LTE coverage complemented by another VoIP capable packet Switched technology, such as HSPA or 1xEVDO, including the following functionalities:

� QoS handling to guarantee a high quality MMTel service. Voice media is therefore mapped to Guaranteed Bit Rate (GBR) bearers, and SIP signaling is protected by mapping in to non-GBR dedicated bearers.

� Mobility based on internal EPC/LTE procedures, which are transparent to the IMS/Application layers. If complementary Packet Switched technologies are used for coverage, IRAT PS Hand Over is also included.

� Advanced radio features like LTE DRX mode for terminal battery saving and Robust Header Compression (RoCH) techniques to improve voice efficiency.

� Self management of Supplementary Services via Web Portal or terminal browser (standard http based interfaces from 3GPP).

� GSM-alike subset of MMTel Supplementary services supporting smooth evolution towards the full multimedia capabilities.

Figure 2.14. Scenario for VoIP over LTE.

Complementary scenarios are also defined in the voice over LTE profile to

cope with the cases where LTE coverage needs to be complemented with

47

existing WCDMA/GSM CS coverage. For these scenarios, the previously mentioned 3GPP CS co-existence mechanisms are included: IMS and SRVCC.

On the other hand, on high level, IMS Centralized Services (IMS CS) provides communication services such that all services, and service control, are based on IMS mechanisms and enablers. It enables IMS services when using CS access for the media bearer, i.e., the CS core network is utilized to establish a circuit bearer for use as media for IMS sessions. In Figure 2.15 is illustrated IMS CS with LTE and 3G access networks.

Figure 2.15. Scenario for VoIP over LTE and 2/3G with IMS CS.

The main IMS CS functions for the voice over LTE solution are:

� The SCC AS, which provides functions specific to IMS Service Centralization and Continuity.

� Enhancements to the MSC-S Server for ICS And the three main IMS CS variants that can be utilized are:

� Access via unchanged MSC-S using Camel home routing. � ICS with Enhanced MSC-S i.e. MSC-S provides UNI to IMS acting

as a SIP User Agent on behalf of the CS user. � ICS with enhanced terminals, i.e., service control signaling between

terminal and IMS, via Gm interface or I2 interface (GSM without DTM).

Furthermore we are presenting two advanced handover for VoIP users:

SRVCC (Single Radio Voice Call Continuity) and IRAT PS. SRVCC is specified in 3GPP TS 23.216. SRVCC allows IMS session continuity when the terminal is Single Radio, thus only one RAT can be active at a time. So when moving out from IMS Voice capable LTE coverage, SRVCC allows MMTel voice continuity via handover to 2G/3G CS. It builds upon ICS, so it relies on the SCC AS to anchor the call and perform the call transfer between LTE and WCDMA/GSM CS access domains. It also needs a new interface between the Evolved Packet Core and the CS Core, the Sv interface, so the MME can request the MSC-S to reserve the necessary WCDMA/GSM CS resources before handover execution. The Single Radio Voice Call Continuity is shown in Figure 2.16.

48

Figure 2.16. Illustration for Single Radio Voice Call Continuity.

IRAT PS Handover is specified in 3GPP TS 23.401. IRAT PS Handover

allows service continuity for all PS sessions between different 3GPP/3GPP2 PS accesses (e.g. LTE and HSPA) in a way that is transparent for the application. Radio resources are reserved in the target network prior to handover, so interruption time is minimized. The user’s IP address is maintained at the GGSN/PDN GW, and IP sessions are transferred to the target network depending on required bearer availability.

Figure 2.17. Illustration for IRAT PS.

Finally, mobile broadband is exploding and LTE deployment is gaining

momentum with mass-market reach expected by 2012. Operators will benefit from evaluating their voice over LTE strategy to take advantage of their strengths before LTE coverage is fully deployed, and link the resulting LTE strategy to communication services evolution and fixed mobile convergence plans.

49

2.5. VoIP over DSL and FTTH

Besides VoIP over wireless networks, in this chapter we will give overview of VoIP over fixed networks: DSL (Digital Subscriber Line) and FTTH (Fiber-to-the-home). Since VoIP over wireless and mobile networks have many challenges and problems to solve (mentioned in the beginning of the previous chapter), before it can give satisfactory level of QoS, in fixed networks many of them didn’t exist. Furthermore, VoIP over DSL and FTTH networks are discussed, as one of the most spread wireline networks today.

� VoIP over DSL

Many of the telephone companies currently providing DSL and landline phone services are in the process of unbundling DSL and phone services. Depending on who your DSL provider is, you may now choose to get only DSL service instead of needing to pay for phone services to get DSL service. The rate for DSL service unbundled from phone service is fairly competitive with cable Internet rates. There is no special LAN connection required for VoIP. The VoIP phone adapter I use connects into the user router just like another PC would. The key is to compare costs of local service to costs of VoIP service before making the connection. You also need to look at what other services you need to connect over your phone lines, like satellite television, for instance. Moreover, as a DSL customer, you need to look at the features you get from the phone company now compared to the features you get for subscribing to a VoIP provider. If the cost of the VoIP service is more than the combined cost of your current local phone service and long distance service, it probably doesn't make sense to switch to a VoIP plan.

Moreover, let we see what is beyond DSL technology? Digital Subscriber Line technology is a copper loop transmission

technology that solves the bottleneck problem often associated with the last mile between Network Service Providers and the users of those network services. DSL technology achieves broadband speeds over the most universal network media in the world: ordinary phone wire. While xDSL technologies offer dramatic speed improvements (up to 7+ Mbps) compared to other network access methods, the real strength of xDSL-based services lies in the opportunities driven by:

� Multimedia applications required by today's network users � Performance and reliability � Economics

As shown in Figure 2.18 one sample comparison diagram, DSL-based

services provide performance advantages for network service users as compared to other network access methods. In addition, DSL-based services provide operational improvements for campus network operators. However, for

50

the purpose of this comparison, the Service User (endpoint location) gains access to a NSP network through a Network Access Provider network.

Figure 2.18. Speed and Performance Comparison.

Figure 2.19. Frequency Division Multiplexing in xDSL.

The PSTN and supporting local access networks have been designed with

guidelines that limited transmissions to a 3,400 Hertz analog voice channel. For example, telephones, dial modems, fax modems, and private line modems limited their transmissions over the local access phone lines to the frequency spectrum that exists between DC or 0 Hertz and 3,400 Hertz. The highest achievable information rate using that 3,400 Hertz frequency spectrum is less than 56 kbps. So how does DSL technology achieve information rates in the millions of bits per second over those same copper loops?

The answer is simple -- eliminate the 3,400 Hertz boundary. DSL, much like traditional T1 or E1, uses a much broader range of frequencies than the voice channel (see Figure 2.19). DSL takes advantage of the spectrum above the telephone audio channel (from about 26 Khz to 1.0 Mhz). Simply put, DSL uses

51

advanced line coding algorithms to effectively divide the spectrum on copper phone wire between voice and data. Such an implementation requires transmission of information over a wide range of frequencies from one end of the copper wire loop to another complementary device which receives the wide frequency signal at the far end of the copper loop.

Moreover, setting up a VoIP connection through DSL connection is similar to connecting through a cable modem. The primary differences are that the users have a different adapter and that adapter connects to the DSL router or modem rather than to a cable modem. Figure 2.20 illustrates a normal VoIP connection through a DSL connection.

Figure 2.20. Connecting VoIP through a DSL connection. To make VoIP connection, users must to follow these steps: 1. Connect the VoIP adapter box to the DSL router or modem. 2. Connect the computer to the VoIP adapter box. 3. Install the software supplied by the VoIP provider. 4. Configure the telephone number and other parameters as directed by

the VoIP provider. 5. Connect a microphone and speakers or plugs to a VoIP headset or

handset. 6. Use the IP soft phone directly from the computer and begin to place

VoIP telephone calls. DSL does not require from users to abandon the POTS telephone nor its

services. Using an inexpensive splitter that plugs into the VoIP adapter box, users can continue to enjoy POTS telephony as well as VoIP.

52

Moreover, DSL runs over the same PSTN CSI that carries the POTS service. To accomplish this feat, the DSL signal is modulated at a higher frequency than the frequency used for regular voice (see Figure 2.19). Analog POTS lines can't support VoIP, but DSL technology — piggybacked on the POTS line — can support it. DSL uses multiplexing equipment that amplifies, regenerates, and reconstructs the VoIP signals so that the packets can travel to and from the Internet in an acceptable manner. A DSL connection is like having two channels that are each operated using different networking techniques, both going over the same physical line. One channel is analog POTS line, and the other is the digital DSL service.

However, like any other network technologies, DSL have their own problems and obstacles: attenuation (the dissipation of the power of a transmitted signal as it travels over the copper wire line) and crosstalk.

One might compare the transmission of an electric signal to driving a car. The faster you go, the more energy you burn over a given distance and the sooner you have to refuel. With electrical signals transmitted over a copper wire line, the use of higher frequencies to support higher speed services also results in shorter loop reach. This is because high frequency signals transmitted over metallic loops attenuate energy faster than the lower frequency signals. One way to minimize attenuation is to use lower resistance wire. Thick wires have less resistance than thin wires, which in turn means less signal attenuation and thus the signal can travel a longer distance. Of course, thicker gauge wire means more copper which translates into higher per foot plant costs. Therefore, telephone companies have designed their cable plant using the thinnest gauge wire that could support the required services.

On the other site, the electrical energy transmitted across the copper wire line as a modulated signal also radiates energy onto adjacent copper wire loops which are located in the same cable bundle. This cross coupling of electromagnetic energy is called crosstalk. In the telephone network, multiple insulated copper pairs are bundled together into a cable called a cable binder. Adjacent systems within a cable binder that transmit or receive information in the same range of frequencies can create significant crosstalk interference. This is because crosstalk-induced signals combine with the signals which were originally intended for transmission over the copper wire loop. The result is a slightly different shaped waveform than was originally transmitted.

Crosstalk is a dominant factor in the performance of many systems. As a result, DSL system performance is often stated relative to "in the presence of other systems" which may introduce crosstalk. For example, the loop reach of a DSL system may be stated as in the presence of 49 ISDN disturbers or 24 HDSL disturbers. As you can imagine, it is rather unlikely that you will deploy a DSL service in a 50-pair cable that happens to have 49 (2-wire) ISDN circuits or 24 (4-wire) HDSL circuits concurrently running in the same bundle. Therefore, these performance parameters typically represent a conservative performance outlook. If the effects of the attenuation and crosstalk are not too significant, the DSL systems can accurately reconstruct the signal back into a digital format.

53

However, when one or both of these phenomena becomes too significant, the signals are misinterpreted at the far end and bit errors occur.

Some DSL systems actually use different frequency spectra for the transmit and receive signals. This frequency separated implementation is referred to as Frequency Division Multiplexing (FDM). With help of these FDM-based systems often VoIP DSL users are achieving better performance than echo-canceled systems, relative to crosstalk from similar adjacent systems.

� VoIP over FTTH

FTTH enables service providers to offer a variety of multimedia services, inluding VoIP, high-speed Internet access, broadcast cable television, direct broadcast satellite (DBS) television, and interactive, two-wat video-based services. All of these services are provided over a passive optical distribution network via a single optical fiber to the home. In addition, an FTTH solution based on wavelength division multiplexing (WDM), or a λ-based architecture, allows for additional flexibility and adaptability to support future services.

When we go back in the time, the telecommunication visionaries have been looking at ways to bring optical fibers all the way to homes since 1972, when John Fulenwider first suggested the idea at the international Wire and Cable Symposium. The first experimental system was installed in Higashilkoma, Japan, in 1978. Others have been tested since then, bur all fiber to the home (FTTH) systems share a common limitation-cost.

Costs can be broken into three components: hardware, installation labor and maintenance. Fiber-optic hardware is more expensive than wires, but unless you are installing sophisticated broadband laser transmitters in each home, the difference is not dramatic cost of terminal equipment such as special interfaces for fiber-optic phones is more of a problem. Designers are working on ways to reduce those costs, but the problem has not been solved. Labor now accounts for a large share of installation costs. The costs of fiber and copper installation are comparable for providing services to new developments but most people live in existing houses. It costs a lot more to install a new fiber-optic connection to an existing house than to leave the old phone wires in place.

Maintenance is another concern. Fiber optic systems generally require less maintenance than copper wires, at least in the trunk and long-haul network. However, phone companies worry that more problems could arise in fiber links to home especially if do-it-yourself homeowners tried to fix their own fiber systems.

Moreover, the importance of FTTH networks is not about the ability to bank online (download music or play impressive video games against like-minded people on the other side of the world) it's about the long term benefits that these networks can bring about.

There are several advantages associated with FTTH including the following:

� It is a passive network, so there are no active components from the CO (Central Office) to the end user. This dramatically minimizes the network maintenance cost and requirements, as well as eliminating the need for a DC power network.

54

� It is a single fiber to the end user, providing revenue-generating services with industry standard user interfaces, including VoIP, high-speed data, analog or digital CATV, DBS, and video on demand.

� FTTH features local battery backup and low-power consumption. � FTTH is reliable, scalable, and secure. � The FTTH network is a future-proof architecture.

Moreover, in Figure 2.21 one example of FTTH network is shown. The

optical multiplexed signal is brought to a splitter in the vicinity of a group of customers. There are optical splitters of different ratios, but the most typical ratio used is 1 to 16. This means the multiplexed signal is split to 16 different households or Optical Network Terminal (ONT, but ITU-T standards refer to it as an ONU). The ONT, installed at the subscriber’s home, converts optical signals to electrical signals for transmission to phones, routers, computers, and Set Top Boxes (STBs) within the home. The ONT can be installed outside the home or it can be installed inside. Inside ONTs are rare in the US because, on existing homes, generally all telephone and cable connections terminate outside, and installing the ONT outside allows technicians easy access for repairs and upgrades (no appointment necessary with the owner). Because the ONTs are expensive, it has been suggested that the resources of a single ONT should be shared among several customers. The Figure 2.21 suggests what the FTTH access network might look like.

Figure 2.21. Example of FTTH realization.

Moreover in Figure 2.22 one concrete FTTH multimedia solution from the Yamasaki (Yamasaki is a diversified global manufacturing and fiber optic technology company. They are one of the pre-eminent fiber optic FTTH Solution Providers, which have developed over 100 types of fiber optic product over the years, including the FTTH products, OLT, ONU, PLC Splitters & PON Power Meters) is illustrated.

55

Figure 2.22. Example of Yamasaki Optical Technology FTTH solution. From the Central Office to the End User’s building, Yamasaki FTTH

solution is reliable, scalable, secure, and extremely future proof. The scalable FTTH networks provide the ultimate super fast broadband solution - the fastest speeds by far - and virtually no limits on capacity. FTTH installations allow for the delivery of multiple services (VoIP, Video, IPTV, Internet and ect.) over the same network, allowing providers to offer bundled services to the consumer. Homes, schools and businesses will be able to enjoy and benefit from services such as VoIP, high-speed Internet, HD television and much more. The possibilities are limitless and the benefits to the subscriber will exceed expectations. As we mentioned before, in a Passive Optical Network (PON) there are no active components from the origination point to the end user. This minimizes the network maintenance cost and requirements, as well as eliminating the need for any form of electrical power along the network, dramatically reducing CAPEX and OPEX. Another benefit is the reduction in Greenhouse gas emissions as PON networks do not require electricity. It is estimated that 10% of the population will be able to work from home, thus reducing the time spent commuting, saving fossil fuels. Fiber has a virtually unlimited bandwidth capacity and is therefore capable of meeting increasing traffic demand of multimedia services, providing a “future-safe” medium that outperforms all other known media. With the prices of fiber optic cable dropping below that of copper, fiber is the natural choice for Greenfield sites. Brownfield sites can also benefit by increasing property value and allowing access to the types of services that only FTTH can provide.

Moreover in the Table 2.5 some modern PON variants are shown. At the moment HFC remains the lowest cost option until significant upgrading is needed. On other words the services available today do not yet need the high capacity available in FTTH. Looking it a different way, the services that require high performance networks have not emerged due to the narrow bandwidth nature of customer connections. Important technical and economical benefits arise from extending fiber to the home compared to today's short term strategies

56

in network topology design. For the operators whose main business is voice, data and interactive video/multimedia services, extending FTTH would create new markets and business opportunities.

One of the technologies that will certainly require more capacity than the current network structure can provide is digital video. Today a digital video channel can be compressed to only require 1.5 to above 6 Mbit/sec (depending on desired picture quality) and progress in the development of HDTV (high-definition television) have lowered the compressed bit rate of HDTV to 20 Mbit/sec. A FTTH network could deliver 5 to 10 limited high-definition programs simultaneously with other services. Consequently, digital video would certainly require FTTH technology to support high bandwidths. Developments in microtecnology have also lowered the costs of decompressor chips making digital video more versatile to the customer. And as demand rises in the next 10 to 15 years FTTH is the best and maybe the only technology easy to evolve to provide higher transfer rates like the standardized basic access rate of 155.52 Mbit/sec known as STM-1. FTTH also offers best solution in terms of upgrading costs. Table 2.5 Modern PON variants.

GEPON or EPON

(IEEE 802.3ah) 1.25 Gb/s Generally requires least capital expenditure as it is an Ethernet standard, and

most compatible with legacy equipment

10GEPON (IEEE 802.3av) 10 Gb/s Ethernet Passive Optical Network, backwards

compatible to GEPON IEEE 802.3ah

GPON (ITU G.984) 2.5 Gb/s An evolution of the BPON standard. It supports a

choice of Layer 2 protocol (ATM, GEM, Ethernet)

57

2.6. Next Generation VoIP architecture

While there are a number of VoIP solutions available today, most of these have limitations of one kind or another. In some cases the solutions are built on early versions of standards and provide restricted interoperability with other vendors. In some cases the solutions do not provide the scalability, robustness, security or features required for PSTN equivalency. The ITU-T NGN standards are providing a next generation VoIP network architecture that provides both full multi-vendor interoperability, and support for a full featured, secure PSTN service and all-IP based core network.

The next step is to develop a coherent solution for scaleable next generation networks that support end-to-end VoIP. This will build on the proven methodology used for NGN Release 1. It will identify open interfaces and define Implementation Agreements for these interfaces. Moreover it will need test plans and conduct interoperability testing to accelerate the deployment of next generation end-to-end VoIP architecture and to accelerate the transition of carrier TDM voice networks to VoIP networks.

The next generation VoIP architecture shall consist of a speech codec, optimized for the Internet, and a corresponding transport protocol. The transmission shall be bidirectional as telephone calls are bidirectional as well. Figure 2.23 gives a first overview on the component of the architecture. It displays just one side of the transmission. However, the other side shall be build similarly. In the following, we describe the components individually.

Figure 2.23. Architecture for a Next Generation VoIP service.

58

In order to optimize the transmission of the telephone call perceptual quality models, which simulate the human rating of the quality of telephone calls, can be applied. The foremost quality model to mention is the ITU’s E-model that is intended to as a planning instrument for telephone systems (see ITU G.107). It considers most of the parameters that have an effect of the transmission quality, such as the loudness of speech signal, the noise levels, the loudness of echoes, the speech quality, and the acoustic mouth-to-ear (M2E) delay. It calculates an overall quality rating called the R factor that ranges from 0 (worse) to 100 (very good). Beside its primary purpose to plan transmission systems, it can also be applied at real time to control a transmission and set the various transmission parameters.

In the novel VoIP architecture a quality model similar to the E-Model is of the utmost importance as it gives an overview on which parameters need to be optimized to achieve a high transmission quality. Also, a trade off between speech quality and delay will be possible. We can also derivate the first building blocks of the architecture, namely the control of loudness with an adaptive gain control (AGC), the cancellation of echoes by an acoustic echo cancellation (AEC), and the determination of the intrinsic delay of a telephone, which are the sum of all delays that the telephone adds to the overall month-to-ear delay. In order to properly approximate the mouth-to-ear delay, the telephone shall determine the intrinsic latency of the speech signal. For example, the AEC can be used to determine this delay.

On the other sides, we must to conceder the VoIP speech codecs, comprising of speech encoder, speech decoder, and loss concealment algorithms, which have been developed and applied in PSTN, cellular networks, and in all-IP VoIP networks. The speech codecs (mentioned in previous module) include ITU G.711, ITU G.729, ETSI GSM-EFR, 3GPP AMR, 3GPP AMR-WB, 3GPP2 VMR-WB, and IETF iLBC. They have optimized to provide a superior speech quality, a low algorithmic delay, a low computational complexity, and high packet loss robustness. At the same time, they require a low transmission bit rate.

But, if this was the case, why should we consider the development of new speech coders if the existing ones are perfect? Three arguments, based on recent research results, have given us the insight that the current speech codecs might not be perfectly matched for the requirements of the Internet. The first is based on the observation that the losses of speech frame can have a quite different impact on the speech quality and that many low rate speech codecs still allow a high loss rate without a hearable degradation of the speech quality. The second is based on the observation that low bit rate it not the only transmission parameter that is of importance in a packetized network. The third argument simply accounts for the observation that telephones are not only used for human to human conversation but increasingly frequent for music listening and music exchange.

Moreover, the Internet optimized speech codec shall not operate on the traditional RTP/UDP protocol. Instead, it requires a transport protocol that informs him on the current state and quality of the transmission path. Only if the

59

speech codec knows the current properties of the transmission path can it adapt its coding bit rate and packet rate to achieve a high perceptual transmission quality. Forward Error Correction (FEC) shall not be a functionality provided by the transport protocol. It can be more easily implemented at the encoder. But then the transport protocol shall inform the encoder about the loss process in the network and the encoder shall change its loss robustness. The transport protocol shall take advantage of the bidirectional nature of a telephone call and shall transmit speech frame bidirectionally. This has the advantage that control information, nowadays transmitted in signaling packets like RTCP, can be piggy back on the data stream. Thus, the packet rate is reduced further. Also, the transport protocol can implement feedback loops to implement rate and congestion control more easily. Optionally, the transport protocol can support other mechanisms such as multi-homing, mobility, multipath, or NAT traversal in order to increase the reliability and quality of the transmission.

However, VoIP can be deployed in many different network segments. To date, it has been mostly deployed in the backbone and enterprise networks. Deploying VoIP as an end-to-end Next-Generation Network solution introduces additional constraints and issues. These issues that need to be addressed in order to provide a toll-quality, PSTN equivalent end-to-end VoIP network, are including:

� Service set to be offered, and the types of end user terminal supported.

� Choice of signaling protocol(s). � Security. � Quality of Service (QoS). � Reliability / availability. � Regulatory Issues � Lawful Interception � Emergency and Operator Services. � Call routing and Number Plans. � DTMF and Other Tones and Telephony Events. � Firewall and NAT traversal. � Billing and Reconciliation. � Network Interconnection. � Migration Path. � OSS support. � Bandwidth Utilization. � Fax, Modem, and TTY support. � Auto-configuration.

Moreover, in Figure 2.24 shows an example VoIP Next Generation

network with 3 service provider networks. -Service Provider 1 is offering local access acting as a LEC. This Service

Provider supports IP phones and IP PBX systems using SIP and POTS phones via either an Access Gateway (Next-Gen DLC) or a Subscriber Gateway (using either H.248 or MGCP).

60

- Service Provider 2 is acting as an inter-exchange carrier (IXC) and supports SIP and SIP-T or BICC signaling through its network.

- Service Provider 3 is offering local access acting as a LEC, but only supports POTS phones using an Access Gateway. SIP signaling is supported but is terminated by the SIP Server rather than using a SIP Phone or other CPE device.

Figure 2.24. Illustration of Next Generation VoIP architecture.

However the provider architecture is - one is unavoidable: Next generation end-to-end VoIP architecture will include within NGN IMS core network. The future VoIP service scenarios will use functional model from Figure 2.5, and will consider the case where the user terminal will have many interfaces (for any used wireless and mobile technology) and for example it will move:

� in a single operator’s network which supports either WiFi or 3G or mobile WiMAX or LTE-Advanced;

� in a multiple operator’s networks, each supporting a different wireless and mobile access networks (e.g. WiFi, mobile WiMAX or 3G/LTE wireless network);

� in a single operator’s network where the user terminal moves between different wireless access networks, e.g. between a mobile WiMAX and a WiFi network.

61

In the following we give one example of service (e.g. VoIP) registration scenario which assumes that the originating user terminal (OUT) and the terminating user terminal (TUT) are located in the same operator’s network which supports either WiFi or 3G or mobile WiMAX or LTE access. In this case, attachment to the network (IP address allocation) and service provider registration (e.g. IMS network registration) is performed. Registration includes:

� network attachment procedures including temporary IP address allocation and registration of the binding between the persistent IP address and the temporary IP address;

� service stratum authentication and authorization procedures based on information included in the service user profile.

Figure 2.25 illustrates the overall procedure related to the registration.

Figure 2.25. Registration process in Next Generation VoIP architecture.

The following describes in more detail the information flows shown in Figure 2.25:

1) L2 MAC layer authentication and authentication, authorization, accounting (AAA) associations are executed by the TAA-FE after connecting to the network;

2) A temporary IP address (network IP address) is assigned to the user terminal by the NAC-FE of NACF;

3) The received temporary IP address from local network is reported by the user terminal to the MLM-FE;

62

4) A service request registration message which contains the user’s URL is sent to the P-CSC-FE by the user terminal;

5) The S-CSC-FE sends a service request registration message which contains the user’s URL and P-CSC-FE URL to the SL-FE via the I-CSC-FE.

Service establishment includes the signalling information flows required for establishment of a communication between the originating user terminal and the terminating user terminal. Figure 2.26 illustrates the overall procedure related to the service establishment.

Figure 2.26. Service establishment in Next Generation VoIP architecture.

The following describes in more detail the information flows shown in Figure 2.26:

1) The service request message sent to the P-CSC-FE by the originating user terminal contains the URL information of both the originating and terminating user terminals, codec information and UDP port number of originating user terminal;

2) The I-CSC-FE interprets the service request message from the originating user terminal;

3) The service request message from the originating user terminal is forwarded to the terminating user terminal;

4) The terminating user terminal forwards the service response message to the P-CSC-FE. This message contains the URL information of originating and

63

terminating user terminal, codec information and UDP port number of terminating user terminal;

5) The P-CSC-FE forwards QoS set up information to the PD-FE. This information includes network bandwidth;

6) The TRC-FE forwards QoS set up information to the IP network elements;

7) The originating user terminal receives a service response message from the P-CSC-FE.

Data transfer configuration covers the use of the Real-time Transport Protocol (RTP) for the transfer of Voice over IP. Figure 2.27 illustrates the overall procedure related to the data transfer configuration. The following describes in more detail the information flows shown in Figure 2.27:

1) The RACF sets-up a pre-established path with the same QoS characteristics as established between the OUT and TUT during the service establishment phase;

2) An RTP session is set-up between the originating and terminating user terminals;

3) Bidirectional data is forwarded between the originating and terminating user terminals.

Figure 2.27. Data transfer configuration in Next Generation VoIP architecture.

Service release includes the necessary information in order to release an

established VoIP session between two user terminals. Figure 2.28 illustrates the overall procedure related to the service release.

64

Figure 2.28. Service release in Next Generation VoIP architecture. The following describe in more detail the information flows shown in Figure 2.28:

1) In order to release the VoIP session, the originating user terminal sends a BYE service request message to the P-CSC-FE;

2) The I-CSC-FE interprets the BYE service request received from originating user terminal;

3) The P-CSC-FE forwards the QoS release information to the PD-FE; 4) The TRC-FE transmits the QoS release message to the IP network

elements; 5) The P-CSC-FE forwards the BYE service request to the terminating

user terminal; 6) The terminating user terminal sends a service response message to the

P-CSC-FE; 7) The P-CSC-FE transmits the service response message to the

originating user terminal. The RTP (Real Time Transport Protocol) session is closed.

In case the terminating user terminal initiates release of the VoIP session, the following changes apply;

- the terminating user terminal transmits a BYE service request message to the P-CSC-FE instead of the originating user terminal (1),

65

- the P-CSC-FE forwards the BYE service request to the originating user terminal instead of the terminating user terminal (5),

- and the P-CSC-FE transmits the service response message to the terminating user terminal instead of the originating user terminal (7).

Furthermore, we describe a scenario in which we present a case where a user terminal moves between different access networks within same operator’s network. In this scenario, handover using the “make-before-break” concept required in order to support service continuity. This scenario is composed of the registration, service establishment, data transfer configuration, handover establishment and service release too. The registration, service establishment, and data transfer configuration are the same us we described in the Figures: 2.25-27. Handover establishment covers the required signalling based on the “make-before-break” concept. Figure 2.29 illustrates the overall procedure related to the handover establishment during the VoIP data transfer.

Figure 2.29. HO establishment in heterogeneous Next Generation VoIP access

networks.

The following describes in more detail the information flows shown in Figure 2.29:

1) A temporary IP address (Network IP address) is assigned to the originating user terminal by the NAC-FE (e.g. via DHCP) after L2 MAC layer authentication and AAA associations by the TAA-FE;

66

2) The originating user terminal informs his moving status to the MLM-FE through the using of a binding update message. In this case, the originating user terminal signals its moving from the mobile WiMAX network to the WiFi network;

3) The MLM-FE updates the mobility management table for location management of the originating user terminal;

4) The MLM-FE informs the SCF of the updated location and QoS profile information of the originating user terminal;

5) The MLM-FE forwards the binding update message received from the origination user terminal to the in-service terminating user terminal in order to inform the changed location information of the originating user terminal;

6) The S-CSC-FE forwards the updated location information of the originating user terminal to the terminating user terminal;

7) The HDC-FE informs to the PD-FE of the creation of a new path between the originating user terminal and the terminating user terminal;

8) The TRC-FE sends a resource reservation request for a new path to the mobile WiMAX network which the terminating user terminal is connected;

9) The TRC-FE sends a resource reservation request for a new path to the WiFi network on which the originating user terminal is connected.

Service release covers the required information for call termination. Figure

2.30 illustrates the overall procedure related to the service release.

Figure 2.30. Service release in heterogeneous Next Generation VoIP access networks.

67

The following describes in more detail the information flows shown in Figure 2.30:

1) The originating user terminal transmits a BYE service request message to the P-CSC-FE;

2) The P-CSC-FE forwards the BYE service request message to the terminating user terminal;

3) The terminating user terminal forwards the service response message to the P-CSC-FE;

4) The P-CSC-FE forwards the QoS release information to the PD-FE; 5) The TRC-FE transmits the QoS release message to the IP network

elements within the mobile WiMAX network; 6) The TRC-FE transmits the QoS release message to the IP network

elements within the WiFi network; 7) The P-CSC-FE transmits the service response message to the

originating user terminal, and the RTP (Real Time Transport Protocol) session is closed.

In case the terminating user terminal initiates the off-hook, the following changes apply:

� the terminating user terminal transmits a BYE service request message to the P-CSC-FE instead of the originating user terminal (1);

� the P-CSC-FE forwards the BYE service request message to the originating user terminal instead of the terminating user terminal (2);

� the originating user terminal forwards the service response message to the P-CSC-FE instead of the terminating user terminal (3);

� and the P-CSC-FE transmits the service response message to the terminating user terminal instead of the originating user terminal (7).

68

2.7. NGN VoIP regulation and business aspects

� VoIP regulation aspects

Defining the appropriate level of regulation for different VoIP services is one of the most desirable issue. On the other hand, due to the large variation in VoIP regulation and the ongoing work in EU, in USA and in the world, here we will focuse on the regulatory situation in EU (based on the ongoing work of the European Regulator Group (ERG) VoIP group). Also, a brief case study from US VoIP regulation is presented.

One of the goals of the European Commission is to harmonise the legislation in EU countries. The tools to make this happen are the directives, regulations and decisions of the European Parliament and of the Council and Commission. These bodies can also give resolutions, recommendations and opinions that are not binding. Regulations are binding and directly applicable in all EU countries. Directives are to be adapted to national legislation within certain time frame and decisions obligate the named member state governments or private persons. In some areas directives impose only the minimum level of regulation that has to be applied and the EU member states can make additional national requirements. However, in some areas, including competition legislation, directives impose also the maximum legislation that can be set. This applies also to VoIP services.

According to the EU regulatory framework, all actions taken by the NRAs and EU Commission should be proportionate to and aimed at achieving the following policy objectives:

� Promote competition by removing competition restrictions, enabling efficient infrastructure investments and promoting innovations.

� Contribute to the development of the internal market. The goal of this requirement is to encourage the development and interoperability of pan-European networks and services by harmonising the national legislation and requirements.

� Promote the interests of the EU citizens that can be achieved by maximising user benefit in terms of choice, price and quality and ensuring access to universal service, high level of consumer protection, network and service integrity, security and data protection. Also needs of special groups, such as disabled users, have to be taken into account.

Taken regulatory measures should also be proportionate to the following regulatory principles set by the Framework Directive and some other directives: objectivity, technological neutrality, transparency, non-discrimination and proportionality. The described requirements set also basis for VoIP regulation in

69

EU. The EU regulatory framework defines the following service categories that can be applied to VoIP services:

� Electronic Communication Service (ECS) is defined in Framework Directive (Art 2c) as a service that is:

- normally provided for remuneration - which consists wholly or mainly in the conveyance of signals

on Electronic Communications Networks � Publicly Available Telephony Service (PATS) is defined in

Universal Service Directive (Art 2c) as a service that is: - available to the public - for originating and receiving national and international calls - access to emergency services - through a number or numbers in a national or international

telephone numbering plan

Furthermore, the regulatory requirements for VoIP services can be divided into three categories that are the following:

� Telephony service specific requirements: Telephony services have traditionally been heavily regulated. However, most of these regulations, like provision of operator assistance, directory enquiry services, directories and itemised billing, are also applicable for most VoIP services.

� Common ECS requirements: In most countries laws and NRAs have defined some requirements common for all electronic communication services, like data protection, security and legal interception. These requirements are valid for all publicly available VoIP services.

� VoIP specific requirements: In some countries, regulators have also defined some VoIP specific requirements and service limitations, like allowing VoIP services to be offered only using some VoIP specific number ranges or limiting the number portability. In some countries the protectionism is used even in larger extend and VoIP usage is either prohibited or service providers are issued with extra taxes.

It should be noted that the regulatory approach agreed today for VoIP services will have a long term impact on the regulatory model on electronic communication market. In the future all communication services will be IP based thus the today agreed regulatory approach for VoIP will set the guidelines for future rights and obligations.

Moreover, when considering, what regulatory approach should be taken for VoIP services, there is a need to find a balance between different objectives of existing regulatory framework. In EU, the objectives are to promote competition, to contribute to the development of the internal market and to promote the interests of the EU citizens. This question can be approached by defining service classes, (e.g. PATS and ECS in EU) that are to be regulated and the regulatory requirements for each class. The task is not easy, because the policy objectives are often at least slightly contradictory. Nearly all obligations impose extra costs to VoIP service providers. In addition, some requirements

70

may not be technically viable and would prevent companies from creating new innovative services. The author believes that if the technical and economic feasibility are taken into account, many obligations are justified for protection of end users (e.g. emergency calls) and promoting of competition (e.g. number portability). In light of technology neutrality, many regulators believe that the same level of regulation should apply for both traditional circuit switched voice and corresponding VoIP services and regulations should be levelled equally from all telephony services regardless of their technical implementation.

Moreover, the ability to make emergency calls is typically considered to be the most important regulatory requirement and therefore it has been debated a lot. In principle, access to a national emergency number can be arranged without significant difficulties at least for all VoIP services at fixed or otherwise known location. Nevertheless, in most cases at least national gateway for each country will be necessary. Due to the problem to locate nomadic users, the routing to the correct emergency center obligation cannot at least currently be always applied for nomadic services.

As it can be seen from EU PATS definition, emergency calls have been used as one of the basic service classification criteria, but the author believes that it would be a better approach to leave emergency calls out of the PATS definition, because otherwise service providers could choose not to provide emergency calls to escape also other telephony related regulations. The better approach would be to set the emergency call requirement separately to PATS services.

- VoIP Regulation Status in EU and USA The Telecommunications Act of 1996 promotes competition and reduces

regulations to ensure lower prices and high quality telecommunications services for all American citizens. Trojecki (2005) summarizes the objectives of the act as “to promote competition and reduce regulation in order to secure lower prices and higher quality services for the American telecommunications consumers and encourage the rapid deployment of new telecommunications technologies”.

Under this act, competitive local exchange carriers (CLEC) are permitted to use local exchange carriers (LEC eg. Verizon) networks and LECs can enter the long distance business. VOIP providers can use the CLEC networks to bypass LECs and their associated access fees. LECs view VoIP as a telecommunication service and believe that the same regulations that apply to voice over circuit switched networks should be applied to VoIP. McPhillips argues that it is difficult to distinguish the real-time full duplexed voice bits from other bits in the public Internet data stream when placing a PC-to-PC VoIP call. This requires the entire Internet to be regulated and monitored, which defies the concept of Internet neutrality. For the PC-to-phone method, locating the originator can be challenging for the termination service provider, for example Qwest. This challenge creates fee and tariff problems.

VoIP providers, on the other hand, argue that VoIP is an information service and should not be regulated. On October 18, 2002, AT&T, an early adaptor to the VoIP technology, petitioned the Federal Communications

71

Commission (FCC) to remove access fees for phone-to-phone VoIP service. On April 14, 2002, the FCC ruled that AT&T is a telecommunications service and therefore must pay access fees. Trojecki (2005) states that the “AT&T petition put the FCC into uncomfortable position.” According to this ruling, the FCC is not promoting competition, creativity, and new technologies as stated in the Telecommunications Act. The FCC must ensure that it is promoting public interests when deciding the fate of VoIP. This is required to promote competition and reduce service prices. It is my position that VoIP should be ruled as an information service and should not be under any state or federal regulations.

Public interest should be the main factor in regulating VoIP service. Trojecki (2005) points out that “states receive a combined $26 million dollars a year from taxes on telecommunications carriers.” The Public Utilities Commission (PUC) has a stake in regulating VoIP, since it will translate to more taxes and tariffs. The US District court ruled against the Minnesota PUC in a ruling regulating Internet service providers. The FCC study that was requested by Congress in 1997 proves that unregulated information services pose a threat to the Universal Service Fund. This study is known as the Steven’s Report, named after Ted Steven of Alaska. The proposed VOIP Regulatory Freedom Act (VRFA) would “prevent the imposition of harmful obligations or patchwork of multiple and discriminatory regulations on the providers of applications that utilize the Internet Protocol or any successor protocol to offer two-way or multidirectional voice communications” (Winstanley 2006, 21). Winstanley (2006) continues, “the VRFA does attempt to level the playing field, however, by providing that VOIP services shall contribute directly or indirectly, to the preservation and the advancement of the Federal Universal Fund programs based on a flat fee.” It is my opinion that the FCC should pave the way for new entrants to compete, not burden them with taxes and fees.

VoIP is regulated differently in the European Union. Nieminen (2004) states that “the objectives (of the EU) are to promote the competition, to contribute to the development of the internal market and promote the interests of the EU citizens.” VoIP is categorized depending on the type of market offering. For example, self provided VoIP fall outside of the EU regulation. For most VoIP enabled devices, users can place calls to other users using the same device, over the internet, without any regulations. Another category is “Carrier internal use,” in which wireless carriers move voice traffic over to IP networks and implement VoIP trunking. This is outside of the EU regulation framework. It is my contention that lighter regulation could be applied to all telephony services, including VoIP services that are classified as publicly offered services. The objectives of the EU are similar to those of the Telecommunications Act and so, similar guidelines should be put into place in the US.

The regulatory framework for VoIP in the United States must be studied carefully. Excessive regulations will negatively impact the innovation of new technologies, new entrants in the market, and the American job market. Trojecki (2005) presents an example of one VoIP provider’s position. Jeffery Citron, CEO of Vonage Holdings Corporation, describes the path that his company will follow if VoIP is regulated, stating that “VoIP providers would offer their services from

72

offshore locations at the expense of American jobs, tax revenues and outside of the control of domestic legal authority.” This clearly states that VoIP service providers will move their businesses and call centers outside of the US where there are no regulations, low capital expenses, and low operational expenses. Overregulation of VoIP would burden the new VOIP entrants and cause them to seek offshore business, which will negatively impact technology innovation, competition, and the economy.

As a conclusion of the regulatory part of this section, we can say that VoIP

services have faced very diverse regulations around the world, and the regulations still differ from country to country. However, the regulatory situation has moved towards a more harmonised approach during the last two or three years. The author believes that this trend will continue also in the future. Moreover, achieving global VoIP regulatory harmonisation will be a very difficult task. The current regulatory practise regarding telephony services was devised at a time when the dominant technology used was fixed and circuit switched and it is not totally applicable for VoIP services. Some requirements, like power supply, are not technically feasible or the authorities may not just be able to control the compliance due to the fact that the service is provided from abroad. It is equally important that VoIP will break the telephony service monopolies. Therefore, a new regulatory approach is needed. The author believes that it is possible to apply lighter regulations for all telephony services in the near future. However, this does not mean that all regulatory obligations should or would be removed. For example the emergency call requirement is likely to remain for services classified as telephony services.

In addition, a large variety of other requirements will apply for all publicly available VoIP services. At least security and privacy protection obligations are likely to be applied also in the future. In fact, these requirements may become to be the heaviest burden for new VoIP entrants.

� VoIP Business aspects

The business environment has changed dramatically, mainly because of the rapid development of communication technology (VoIP) within the last decade. Globalization and market liberalization has altered the way a firm competes within this environment and how the firm interacts both with its customers and suppliers. For example:

� Both customers and competition have become global. To cut cost and to ensure easy access to customers, production and sourcing have shifted overseas.

� Technology has become complex and sophisticated. � The use of communication networks is widely available at many parts

of the world. � More firms than ever are using technology for a variety of tasks and

several options exist for technology procurement. � Through the use of the Internet, customers have access to a wealth of

information about products, markets, and a firm’s competition.

73

� Customers have become more demanding interms of price, features, product quality, delivery, level of service, and responsiveness.

� To manage customer expectations and needs firms have begun to form alliances and partnerships to manage their supply chain.

To compete in this new economy firms are looking at many strategic options.

Recent events noted below suggest that firms, in particular large ones, are exploring the use of VoIP as a means to cut costs, to improve productivity, and the firm’s strategic position:

� Bank of America is deploying more than 180,000 Cisco VoIP phones across its branches

� Boeing has announced plans to equip its 150,000 workers with VoIP � Ford has a deal with SBC to deploy 50,000 VoIP phones � Vonage has nearly 600,000 customers and new subscribers at the rate

of 15,000 per week � BT, the major telecommunications player in UK has announced that it

plans to convert its infrastructure to VoIP by 2009.

VoIP is a relatively new technology. As with any new technology, some firms quickly adopt technology while other firms either wait or ignore it. Moore (1991) developed a model for categorizing new technology adopters. According to Moore, based on the time of adoption, firms may be placed in one of five categories: innovators, early adopters, early majority, late majority, and laggards. It could be argued that firms may not be ready for another substantial investment especially if they made a recent investment in mobile and cellular services. But, published information within USA lend to the notion that the investment in VoIP is accelerating.

For example, telecommunications giants such as Avaya (http://www.avaya.com) and Cisco (http://www.cisco.com) report successful implementations in hundreds of diverse firms. This could imply that VoIP adoption is in the early majority phase (Walker and Hicks 2004). But, in other countries, the situation may be different if these countries do not practice free market policies. In market economies such as USA, the individual firms make the determination on the decision to adopt VoIP technology. But in many third world countries, state enterprises often operate the telecommunication services and these enterprises may not be quick to adopt VoIP technology if such technology is seen to have a negative impact on their profitability.

The literature is rich with “how to” articles and possible benefits, costs, and implementation barriers. VoIP has not shown to have a clear economic advantage of the traditional phone systems. Some practitioners suggest that VoIP is all hype and may not be the right choice for some organizations if:

a) voice quality and reliability are of paramount importance to the organization,

b) power or high speed Internet connections are unreliable, c) the VoIP does not have the needed features, d) high speed Internet is not available,

74

e) high speed Internet usage is near capacity, and f) capital costs (Britt, 2005).

In that context, let we see short analysis in order to evaluate the internal and external factors positioning the VoIP business in the market. The objective of this analysis is to obtain an overall assessment of the current strengths, weaknesses, opportunities, and threats (SWOT) of implementing VOIP.

- Strengths:

• VOIP is supported by most platforms.

• VOIP is more efficient in bandwidth utilization.

• With its IP underlying protocol, VOIP is an open standard.

• The integration of VOIP gateways and the bypassing of the PSTN allow for significant international and long distance toll call savings, which reflects positively on the shareholder value and ROI.

• Converging data and voice networks will reduce maintenance, management, and physical equipment costs. It will introduce advanced features and increase bandwidth efficiency.

• The concept of unified messaging increases the efficiency and productivity of sending and receiving email, short messages, and faxes from PCs, phones, and handheld devices.

- Weaknesses:

• Some standards are set by the ITU, but the technology is not fully standardized, which means that there is no guarantee that products from different vendors will interoperate.

• Quality of Service is improving but does not guarantee that network congestions will not degrade service.

• Immaturity of the technology and lack of standards could pose an issue. IT managers would like to see successful scenarios of implementation to be comfortable making the final decision.

• With one converged network, a major issue could result in failure of the system and lost data and voice communications capabilities. That’s why during the planning phase those failure problems must be solve (predicted) or reduce. Because of that and because of many reasons, the planning is the most critical phase in VoIP project deployment (Estimated at 8 to 12 months, planning is considered the largest portion of the VoIP project time cycle).

75

- Opportunities:

• One converged network provides more control. Vendors can offer monitoring, alarming, and accounting logs.

• VPN incorporation for encryption and enhanced security can be easily achieved with VOIP.

• A reduction in overall expenses and capitalization (less network structure) will increase company value as well as shareholder and investor satisfaction.

• VOIP allows enterprises and businesses to exploit data networks and to link these networks to e-commerce, which creates more efficient business transactions. For example, a customer can click on the link available at the Company X website to start a conversation with the front desk representative or a project manager.

- Threats:

• Attacks from intruders could result in lost communications.

• Lack of interoperability is a potential problem for future upgrades or equipment price negotiations.

• With e-commerce growing rapidly, the slow implementation of VOIP could negatively impact business.

• Quality of service could be negatively impacted, affecting business conduct when network traffic is high.

However, the main advantage of VoIP lays in the fact that it is more efficient

and less expensive than circuit-switched telephony, allows for “killer applications” and, in its purer forms, is portable. A VoIP subscriber can make and receive calls anywhere in the world that he can find Internet access.

These advantages over Plain Old Telephone Service (POTS) are leading many independent cable operators to consider deploying VoIP.

76

References

[1] ETSI TS 123 003: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); Numbering, addressing and identification".

[2] ITU-T Recommendation E.212: "The international identification plan for mobile terminals and mobile users".

[3] ITU-T Recommendation E.164: "The international public telecommunication numbering plan".

[4] IETF RFC 3761: "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)".

[5] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture Release 1".

[6] ETSI ES 282 002: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN Emulation Sub-system (PES); Functional architecture".

[7] ETSI ES 282 003: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Resource and Admission Control Sub-system (RACS); Functional Architecture".

[8] ETSI ES 282 004: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture; Network Attachment Sub-System (NASS)".

[9] ITU-T Recommendation E.164.1: "Criteria and procedures for the reservation, assignment and reclamation of E.164 country codes and associated identification codes (ICs)".

[10] ITU-T Recommendation E.195: "ITU-T International numbering resource administration".

[11] ITU-T Rec. Y.2216, ‘NGN capability requirements to support the multimedia communication centre service’.

[12] ITU-T Rec. Y.2205, ‘Next Generation Networks – Emergency telecommunications – Technical considerations’.

[13] ITU-T Rec. Y.2211, ‘IMS-based real-time conversational multimedia services over NGN’.

[14] ETSI TS 123 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2".

77

[15] ITU-T Rec. Y.2237, ‘Functional model and service scenarios for QoS enabled mobile VoIP service’.

[16] ITU-T Rec. Y2012: ‘Functional requirements and architecture of the NGN’.

[17] ITU G.107, “The E-model, a computational model for use in transmission planning”, Mar. 2005.