Part I: ACCESS AND BACKHAUL NETWORKS

1

ROADMAP FOR NEXT-GENERATION COMMUNICATIONS NETWORKS

María Ángeles Callejo Rodríguez and José Enríquez Gabeiras

In recent years, multiple initiatives to progress on the building of the Future Internet have been launched worldwide (such as GENI [1] and FIND [2] in the United States, the “Future Internet Assembly” [3] just built in Europe, and the Akari Project [4] in Japan). In all these innovation programs, the research community is proposing new evolution strategies for the present Internet that, from the point of view of maintaining the present status quo, are either revolutionary or evolutionary. In the case of revolutionary approaches, the so-called “clean slate” approach is proposed in order to consider new requirements since the initial phases of the design of new networks (such as security or new network virtualization techniques), disregarding any demand for compatibility with the present infrastructure. On the other hand, the evolutionary path has as a starting point the current Internet infrastructure, transforming the architecture of present Next-Generation Communications Networks to meet the requirements of the services of the future.

This chapter aims to provide an (a) overview of how this evolution of Next-Generation Communication Networks is being done and (b) a summary of its role to build up the Internet of the Future. It aims to identify the main requirements for the network of the future, and it discusses how the improvement of the current Next-Generation Network (NGN) capabilities should be the basis to provide them. In order to fulfill this view, the chapter first presents the set of goals to be met by future networks considering the users’ behavior and the evolution of Internet traffic, then analyzes the main problems and solutions associated with QoS (Quality of Service) provision, and finally proposes a roadmap to steer the evolution of present networks to the multiaccess, multitransport Future Internet.

1.1 REQUIREMENTS FOR NGN AND THE ROLE OF QoS FOR THE FUTURE INTERNET

As a first step to build the Internet of the future, it is mandatory to analyze the expected evolution of the Internet users’ behavior. One of the main characteristics of present-day network planning is the high uncertainty of the users’ demand evolution. Nowadays, the main characteristic of the end users is their diversity: There are multiple applications with heterogeneous requirements (Peer-to-Peer, streaming, voice over IP, blogs, social networks, chats, gaming, etc.), which can be accessed from multiple devices (mobile devices, PCs, game consoles, etc.) using different types of connectivity (mobile of different types, fixed by different media).

There have been multiple attempts to evaluate how the different Internet users behave, but, probably, in order to define the requirements for the Internet of the Future, a classification of the end users’ behavior according to their age could be the best approach to foresee what is expected in the future from the end users’ perspective. In this sense, the popular generation tagging has identified the following generations:

  • Generation X (born in 1960s and 1970s) uses the Internet for web navigation and access to mail.
  • Generation Y (born in 1980s) is all day connected, so this generation considers ubiquity and reliability in their Internet connections.
  • Finally, Generation Z or digital natives (born in 1990s and 21st century) is used to the technical changes and has much more knowledge about the technology [5]. This generation is highly connected and makes a lifelong use of the communications and media technologies.

It is clear that in a short time span, different patterns of usage of the network have arisen, due to the ever richer offer of services being offered and to the lower entry age to the Internet. Therefore, regarding connectivity, many new requirements must be considered in the evolution of NGN: future networks must support new traffic demands, reliability to allow the end users to trust the availability of their connections, ubiquity of the access, security in the service usage, flexibility to adapt to the different requirements, neutrality and openness to allow the development of new services, and ability to provide advanced services which combine all these characteristics.

An important indicator to evaluate the capacities to be provided by future networks is to evaluate how the traffic will evolve in the coming years. As stated by Cisco [6] and represented in Figure 1.1 [6], it is clear that we are witnessing a huge increment of the demand of new multimedia applications that require better network performances or guaranteed QoS, such as online gaming, video streaming, or videoconference.

Figure 1.1. Evolution of Internet traffic per application type [6].

c01f001

Moreover, this will be especially demanding with the above-mentioned new generation of young people that is “always on” in Internet, is also able to create their own services, and values the connectivity as an important service, for which they are keen to pay to have the possibility to access the wide set of Internet services. The provisioning of advanced QoS connectivity services will become a key driver for the operators’ business role in the Future Internet.

In this process to build the NGN, due to the strategic role played by the standards in innovation, competition, and regulation, it is important to identify any standardization gap in order to guarantee the fair play of the different players while building the technology roadmap. In this context, the specification of the NGN architectures will play a key role. But, what are the main objectives of the NGN? It is generally agreed that the main focus of the NGN could be summarized in the following key topics:

  • To provide better access: In the context of NGN, we include the evolution of access and core technologies which are able to provide higher bandwidths in both fixed and mobile technologies. The evolution of all these technologies is one of the main topics addressed by this book in next chapters.
  • To be able to efficiently carry different services: One important topic being fostered by the NGN architecture is the integration of multiple services into IP networks. All these services must be integrated in such a way that carrier-class capabilities should be also provided. This would allow the operators to provide their services (both corporate and residential) over the same network; moreover, this could represent an opportunity to offer these capabilities to other service providers that do not own network infrastructure. In order to effectively make this scenario possible, all the features related to the provisioning of different services in the NGN networks should be implemented in such a way that simplicity for end users’ and operators’ management is a given.
  • To integrate mobile and fixed architectures and services: Since the end users are accustomed to connecting to the Internet from multiple devices and types of networks, it can be naturally expected that in the future all the services will be accessible from any type of network by adapting to the transmission and terminal characteristics.

This chapter will focus on how the NGN control capabilities should evolve in order to make possible the provisioning of QoS and the convergence of network services in an efficient way, independently on the usage of fixed or mobile access, which means to avoid introducing unnecessary complexity that could make the solutions practically unfeasible. This chapter does not focus on the evolution of the network technologies that could make possible the provisioning of more advanced communication features (this, in fact, is the main purpose of the rest of the book), but is more focused on how the different mechanisms to control all these features should be implemented and standardized in order to really make possible the NGN objectives.

In order to evaluate how these control mechanisms for NGN should be implemented, first and foremost, it would be important to take a look at how the NGN is structured. In ITU-T [8], a draft architecture of the NGN is depicted and described. In this architecture the following strata can be distinguished:

  • The Transport Stratum, including:
  • The transport functions (in the access, metro, and core network). The evolution of all these functionalities are related to the evolution of the network technologies itself (new optical solutions for the core networks, FTTH, new wireless mechanisms, etc.).
  • The transport control functions (resource and admission control functions and network attachment control functions). Currently there are several standardization bodies in charge of leading the evolution of this control plane: ETSI/TISPAN [9], 3GPP [10], and ITU-T [11].
  • The Service Stratum, which includes the service control functions (including service user profile functions) and the application and service support functions. In principle, any service stratum can use the transport stratum capabilities, but the most clear standardization (and also commercial) initiative proposed so far is the IMS (IP Multimedia Subsystem), fostered by the 3GPP, which specifies an environment where the network operator is in charge of providing the services, which also takes advantage of the control functionalities.

Therefore, taking into account the foreseen users’ requirement for improved QoE, and considering the various technology-centered solutions proposed in the realm of NGN to provide QoS, one of the major challenges is to guarantee the users’ QoS requirements between the end points involved in a communication that spans over several network segments. As explained in ITU-T [7] and [8], a new architecture must be designed in order to address this goal, whose main feature is to integrate and synchronize the tasks performed in the different planes of the networks along the e2e (end-to-end) path. Moreover, the solution must also consider the interaction with the Home Gateway, since this entity is in charge of managing the Home Network, which represents the first and/or last part of the entire network chain and will play a key role in the provision of quality communications to the end users.

In this sense, the role of the transport control functionalities is the key for the success of this e2e QoS provisioning. Even though a multiple standardization effort has been invested in order to design and implement this control function in ETSI/TISPAN [9], 3GPP [10], and ITU-T [11], there is still not a common solution, since each standardization body is focused on different technologies, and the proposed solutions are offering different interfaces for resource reservation and enforcement. Therefore, up to now only partial solutions to provide QoS in specific underlying technologies are implemented, and these do not have e2e significance. Besides, these solutions usually require a manual administrator configuration (which in fact leads to high operational effort) and are therefore hard to reconfigure according to the online users requests.

In the next subsection, an overview of an experimental system to address this problem is provided (the EuQoS system). This system was designed to build a framework able to provide e2e QoS over heterogeneous networks. The design and implementation of this system has allowed the authors to identify the problems that exist today in current specification of NGN transport control functionalities and to provide a set of recommendations to support the development of an architecture able to make possible the integration of fixed and mobile access to provide any carrier-class IP service.

1.1.1 The EuQoS System as a Solution to Provide End-to-End QoS

The EuQoS Project [12] main achievements have been the design, development, integration, testing and validation of QoS mechanisms over heterogeneous networks while preserving the Internet openness principle. In a nutshell, the EuQoS system has provided a new approach that allows the Network Operator to take advantage of the requirements of new Internet Services as the driver for a new commercial offer based on advanced connectivity requested by the end user.

The EuQoS system architecture that is presented in Callejo et al. [13] allows the network operators to provide e2e QoS connections over heterogeneous network technologies. This approach considers that Net Neutrality will be both a users’ and regulators’ requirement in the Future Internet, and therefore the system must enable the end user to request a specific type of connectivity service to the network (Real Time, Non-Real Time, etc.), regardless of the Service Provider particular end-services, which means that no linkage between applications and service levels can be set beforehand. The EuQoS system is able to effectively guarantee e2e QoS according to users’ demands by means of coordinating the QoS mechanisms available in the different network technologies along the communications path. This is done by specifying a set of well-known e2e Classes of Services (known by the end users) that are mapped to the different underlying network mechanisms in each communication segment. In order to ensure the scalability of the solution, two timescales are specified: the long timescale process of the provisioning (where resources are reserved per aggregate according to the dimensioning of the network and expected users’ demand) and the short timescale of session setup by the end users (where the processes available in the access technologies should be triggered in order to use the provisioned paths in the longer timescale).

In order to build, use, and monitor the QoS guaranteed paths, an architecture based on different planes is proposed in Callejo et al. [13] and is depicted in Figure 1.2, where the main planes and interfaces are shown. Next, the implemented functionalities are briefly described:

  • The Service Plane provides the QoS on demand interface that allows the end users to request QoS guarantees for their applications. Moreover, this Service Plane also implements the AAA (Authentication, Authorization and Accounting) and charging functionalities. This interface provides QoS as a service that can be used by any application/service without the need of integrating the full stack of the application signaling in this Service Plane.
  • The Control Plane is in charge of the control procedures to ensure the provisioning of the QoS in both provisioning and invocation phases. This plane is split in two different levels:
    • The Network Technology Independent level provides a reference point that is used by the Service Plane and by the Home Gateway to request the reservation of resources; this level manages an abstraction of the domain topology, maintains a set of operator’s policies, the users’ localization, and contacts other domains involved in the e2e QoS guaranteed path using the interface provided by other Network Technology-independent levels.
    • The Network-dependent level provides a well-known interface to the independent level and maps the e2e Classes of Services to the specific underlying network mechanisms, applies specific admission control algorithms (i.e., in mobile networks it can consider physical parameters, while in fixed networks this could be optional), and interacts with the network equipment in order to configure the QoS policies.

Figure 1.2. EuQoS architecture (reference points and protocols).

c01f002

According to the design and evaluation of the EuQoS system, the following design principles must be maintained during the specification of the control capabilities of the networks of the future:

1. A set of well-known technology-independent classes of services must be provided. These e2e classes of services would allow carrying out the same service over different technologies without the need to deploy specific solutions per network type. These classes of services are presented in Reference 14.

2. There must be a clear distinction between the different planes and clear specification of the reference points at each plane and layer. This permits the configuration of multiple scenarios over the same infrastructure (a Home Gateway or a service provider accessing the control plane capabilities directly or the end users using the QoS on demand interface).

3. There must be a distinction between network technology-dependent and -independent mechanisms. This makes the deployment of the solution easier: The ISP or the vendors just need to provide a common interface to make use of the QoS capabilities in their control systems. Moreover, if, in the future this interface is provided by some network equipment, the development of ad hoc control systems could skipped.

All these principles are applicable to the design of the control capabilities to provide QoS guarantees, but some of them could be also applied to other features, such as to ensure the design of management systems.

1.2 PROBLEMS AND RECOMMENDATIONS FOR NGN EVOLUTION

Based on the experience of the authors in the design, implementation, and validation of a system able to provide QoS over heterogeneous networks, this section identifies a set of problems to develop the NGN capabilities and presents a set of recommendations that could feed the standardization process of some ITU-T initiatives for NGN evolution to support e2e management of the services, such as the AMS (Advanced Multimedia System) or any other standardization process.

1.2.1 Problems to Provide QoS in an Efficient Manner

Multiple solutions and architectures were studied during the referred research; as a result, possible weaknesses in present standards and commercial solutions were detected.

Problem 1: Application Signaling Integration with NGN.

Most of the current NGN specifications propose the integration of the application signaling; this means that, in order to provide QoS for specific services, the NGN must not only be aware of the application signaling but also must be an essential part of the service negotiation (e.g., for codecs selections, user discovery, etc.).

A widely known example is IMS, which specifies the usage of SIP (Session Initiation Protocol) as the only way to interact with the P-CSCF (Proxy Call Session Control Function, which is the first point of contact of the end user with the IMS control entities). If SIP is discovered as a protocol not suitable to deal with different types of applications/services, the core of the IMS control will become useless as the Service Plane (or Application Level) of the NGN in the Future Internet networks for any kind of application. In addition, there are some complaints from application developers due to the lack of specification about the actions to be taken when an application signaling event is detected.

Moreover, taking into account the wide variety of application protocols that are currently being used in the Internet (e.g., MSN, Skype, P2P Streaming applications, etc.), if this design principle is maintained, this could lead to complex systems where several gateways should be integrated to interwork with the users’ favorite applications, not necessarily SIP-based. Finally, if we take into account that in the Future Internet the users will not be only service consumer but also service providers/creators, a wide variety of non-IMS applications can be expected to coexist in the future.

To sum up, the requirement of the integration of the application signaling in the NGN structure would lead to two main scenarios:

  • Complex systems in charge of managing multiple signaling protocols or with several gateways where the provisioning of advanced connectivity services for new (and probably users favorite) applications will be delayed. This scenario could lead to a solution difficult to manage due to its complexity and, maybe, lack of scalability.
  • Walled gardens where only specific services will be provided with QoE, losing the openness as a main principle of the Internet. Probably, this option will not even be attractive for the operators, since they will not be able to provide advanced connectivity services to their end users (but the users appreciate the good connectivity service provided by their ISP as the main quality criteria) nor will they be able to provide their network capacities to third-party applications.

Problem 2: Weak Specification of the Interfaces.

In current recommendations and/or specifications, there is a clear weakness in the specification of the interfaces and reference points. This problem is reflected in the following points:

  • There are three standardization bodies specifying the transport control functionalities. Each body proposes different interfaces that, in fact, could lead to interoperability problems. This is something well-identified, and in fact the standardization bodies are trying to converge in a common solution (e.g., there is a clear integration attempt between 3GPP and ETSI/TISPAN).
  • Some interfaces are not specified and are left for further study (such as, e.g., the interface between trusted CPE and the RACF in Y.2111, which will be essential in the full integration of the Home Gateway as an extension of the Operators Control plane).
  • Other interfaces are only specified in terms of methods, parameters, and requirements for the transactions. For these interfaces, there is no clear choice of the protocols.

This lack of clear specification of the reference points could lead the different vendors to provide their own solutions for the whole system. This will lead to interworking problems between the different vendor equipments that, indeed, result in interworking problems for multivendor solutions (i.e., control capabilities of one vendor able to interwork with the transport capacities provided by two different equipment providers) or interoperability problems across different network domains.

As an example, it can be mentioned that in Recommendation ITU-T Y.2111, the details of the interaction between different RACFs (reference point Ri) is left for further study. This interaction is mandatory if QoS information is shared by different domains involved in the end-to-end path; it is being addressed in other standardization bodies and implemented by some vendors, in particular the following:

  • ETSI/TISPAN has provided a draft version of the RCIP (Resource Connection Initiation Protocol) which is specified to allow the interaction between the ETSI/TISPAN RACSs (similar to ITU-T NGN RACF) during the reservation of the resources to ensure a specific QoS level.
  • At the time of this writing, a telecommunications equipment manufacturer1 has released a commercial implementation of a RACS (ETSI/TISPAN module similar to the ITU-T NGN RACF), which provides an RCIP-based interface to allow the communication between different resource managers.

In this scenario, it is very likely that the final specification of the RCIP-based interactions will not meet the real implementation of the commercial equipment produced today, becoming the source of future interworking problems.

Problem 3: Weak Specification of the Modules Functionalities.

The current specification of some modules does not really specify a general state machine of the module and functions. This scenario could lead to vendor-specific solutions, resulting in competitive problems that are not only due to the interworking problems between different vendor equipments but also due to the overlapping of functionalities and/or lack of them.

Therefore, it is felt that the implementation guidelines to support the specification of the interfaces and the development process are missing. This would not mean the specification and standardization of the algorithms that implement the functionalities and that, in fact, could constitute the competitive difference between different providers, but at least to clearly identify input and output parameters as well as the raw description of the processes that should be triggered in each module.

Problem 4: Non-open Interfaces to Configure the Network Equipments.

One of the key points in the provisioning of QoS is the coordination of the different QoS mechanisms available in different network technologies. In order to do that, it is important to have access to the Network Equipments involved in the end-to-end path as well as to have the availability of mechanisms to provide configuration commands to the different equipments.

For instance, during the integration of the EuQoS system with several network technologies, the project had to address several integration problems due to the lack of common reference points in the different network elements. For example, in order to integrate UMTS technology, there were different reference points to interact with the GGSN depending on the vendor provider. This issue resulted in the need for the EuQoS system to relay on the UMTS user interface to setup PDP context as the only possible standard compliant solution to integrate QoS UMTS built-in mechanisms.

Similar problems were faced to integrate the Ethernet technology, where different strategies to interact with the switches had to be followed depending on the equipment vendor.

If non-open interfaces are available in the network equipments, the provisioning of QoS guarantees will be hard to deploy due to the high dependence on specific vendor solutions that will probably try to provide their network control platforms for the new equipments. If this issue is added to the lack of a clear specification of the interface between different control layers (in particular, between the RACS deployed in different domains), this could lead to a general interoperability problem (both between technologies and between domains), rendering the end-to-end QoS provision almost impossible.

Problem 5: The Regulatory Environment Is Not Clear.

Nowadays, multiple regulatory scenarios are being defined across the world with a clear trend toward enforcing some way of functional separation between services and networks operations. In this scenario, all those systems based on the vertical integration of services and networks will probably not be viable. Therefore, a clear specification of the interfaces between service layer and network layer will be necessary in order to ensure the validity of the NGN proposals in different scenarios. This means that NGN specification must meet the requirements imposed by the different roles that could arise in the different business models that can be foreseen for the near future.

In this context, the clear specification of reference points will be mandatory.

1.2.2 Recommendations and Proposals to Provide QoS in NGN

According to the problems exposed in Section 1.2.1 and according to our experience, a set of recommendations are provided in this section in order to allow the integration of end-to-end QoS capabilities in ITU-T NGN.

All the recommendations are made taking into account that Net Neutrality will be a requirement from the end users (who are willing to improve their QoE in Internet) and from the regulators (whose position is clearly against “walled gardens”).

Recommendation 1: Clear Analysis of the Users’ Requirements and Knowledge.

The end users’ behavior has become a moving target in the Internet era. The operators have seen an evolution of a landscape of a single service with a very predictable demand to a situation in which there are a myriad of services, most of them generated by the users, with a demand that is highly unpredictable. Therefore we need to assess the user demand and evolution at this point in time. It is important to carry out market studies in order to know the end-users’ expectations and how they can use the new QoS capabilities with the new services. In particular, at least the following questions must be addressed:

  • What is the end-users’ knowledge about QoS? What do they really know about this concept?
  • Which end-to-end attributes (such as security, reliability, availability, fail recovery, etc.) would be required by the end users?
  • What are the most used end-users devices (IPhone, PDAs, laptops, etc.)? How many attributes should be provided by a common user?
  • What Internet Services are more in demand by the end users? What is the added value of operators’ services perceived by the end users?

With this study, we could characterize the current Internet usage and infer the Future Internet access requirements. Taking into account this characterization, it is important to provide the following conclusions:

  • Identification of the current Internet access limitations in terms of QoS as it is perceived by the end user.
  • Specification of the new requirements for Network Performance, especially taking into account new services such as High-Definition TV (with its associated QoS requirements), 3D Internet applications, or P2P applications. This could be the starting point of the specification of the Future Internet Classes of Services in terms of e2e QoS guarantees (IPTD, IPDV, and IPLR) and other performance metrics (availability, security, fail recovery time, etc.)
  • First draft of the end-user Interfaces that could allow the invocation of advanced network capabilities services.

This analysis will be mandatory in the specification of the AMS end-users reference points; this must be comprehensible by the end user and must be able to support requests for different Internet applications with different QoS requirements.

Recommendation 2: QoS Must Not Be Against Net Neutrality.

The evolution of NGN transport technologies offered as network services create an excellent opportunity for the innovation, but not just for the operators (to provide their own services) but also for end users and service providers. If these capabilities are offered in a fair way, the QoS will be a clear driver for the development of guaranteed services to any party.

Effectively, a framework to provide guaranteed QoS is not necessary for just discrimination or filtering for other non-QoS applications. In order to meet this requirement, it is important that this framework provides to the end users and service providers a (set of) clear interface that could allow the user to decide which QoS level is required for each of his/her flows. In this way, QoS will be provided not only to operators’ services but also to other Internet services according to the end-users’ demands.

If the specified framework meets this requirement, it could allow the network operators to provide their own services and also to take advance on third-party applications (Internet services) as a driver to offer advanced QoS connectivity services. In a scenario where the QoS is offered as a service, it is necessary to provide mechanisms to ensure that the capabilities are effectively provided, and therefore these monitoring capabilities should be linked to the development of the system itself.

Recommendation 3: New Business Models Must Be Drafted.

Clark et al. [15], state that:

One can learn from the past. To some of us in the research community, a real frustration of the last few years is the failure of explicit QoS to emerge as an open end-to-end service. This follows on the failure of multicast to emerge as an open end-to-end service. It is instructive to do a post mortem on these failures.

Here is one hypothesis. For the ISPs to deploy QoS, they would have to spend money to upgrade routers and for management and operations. So there is a real cost. There is no guarantee of increased revenues. Why risk investment in this case?

If the consumer could exercise effective competitive pressure in ISP selection, fear and greed might have driven ISPs to invest, but the competitive pressures were not sufficient. On the other hand, if ISPs use the new QoS mechanisms in a closed way, rather than an open way, they greatly enhance revenue opportunities. Thus, for example, if they deploy QoS mechanisms but only turn them on for applications that they sell, they reduce the open nature of the Internet and create opportunities for vertical integration. If Internet Telephony requires QoS to work, and they only turn on QoS for their version of Internet Telephony, then they can price it at monopoly prices.

This statement lets us think that a possible risk is that the current Internet model could evolve according to the next two threads: a classical best effort Internet (where carriers will limit their investments) and a premium Internet (where ISPs will invest in NGN equipment to ensure high QoS capacities but at high prices).

From the social point of view, this would result in the lack of the universality of the Internet. In this context, the specification of business models to support a better resource usage and economical revenues is a must.

In this context, the study of the evolution of the society will have to be taken into account. In this kind of study, a new generation has been identified as being “always connected” to use a wide variety of services and applications in the Internet (social networks, P2P file sharing, video streaming, videoconference, gaming, etc.); thus, these people would highly value all those connectivity services that are neutral, reliable, ubiquitous, and able to support multiple traffic profile demands. This could be the starting point for the specification of those business models that could guarantee the deployment of end-to-end QoS.

On the other hand, some service providers not integrated with the network providers could have the need to collaborate with the network providers (that manage the last mile of the network) in order to provide carrier-class services. This could be interesting for streaming-based services2 or gaming applications.3

It should be noted that the specification of these business models should also consider the evolution of interconnection agreements.

Recommendation 4: To Promote the Standardization and Implementation of Reference Points in Commercial Equipments.

As stated before, one of the key points in the provisioning of QoS is the coordination of the different QoS mechanisms available in different technologies. In order to do that, it is important to have access to the network equipments involved in the end-to-end path as well as to have the opportunity to introduce some minor modifications in the different equipments.

In order to achieve this goal, the specification of reference points in the different network equipments is mandatory in order to reuse the built-in mechanisms to provide end-to-end QoS. This would avoid some of the same integration problems as those faced in EuQoS during the integration of the UMTS or Ethernet technologies that were described in the previous section.

As a first step in this direction, some companies4 have recently opened their interfaces and operating system in order to allow third parties to implement different applications, such as bandwidth management strategies.

Recommendation 5: To Design a Common Framework to Provide End-To-End QoS: IP Interconnection Models.

In order to really meet the QoS requirement, it is essential to ensure the QoS in the end-to-end path. Therefore the coordination between the different domains and technologies will be required, at least in the different access technologies. As a consequence, it is necessary to promote the specification of a common framework for IP interconnection to be used as the basis for the synchronization of the QoS mechanisms available in different domains. The impact on the routing protocols must be studied. In reference 8, the EuQoS system presents its interdomain routing strategy based on EQBGP that allows the different domains to announce their QoS capabilities.

Therefore, in order to guarantee the provisioning of end-to-end QoS in any network, it is important to define a set of end-to-end Classes of Services (CoS) well known by all the domains (that follow their own strategy to implement each CoS) in order to define a converged policy control infrastructure.

Recommendation 6: Implementation of Preliminary Version of Some Interfaces.

As was stated in the previous section, one of the major problems in the development of NGN architectures is the interfaces specification and implementation. In order to really success in the implementation of the interfaces, it is mandatory to be able to perform interaction tests. For this reason, it would be recommendable to build basic modules in order to launch compatibility tests.

Recommendation 7: To Build a Common NGN Roadmap.

In order to be a reference in the standardization process for NGN, ITU-T, ETSI/TISPAN and 3GPPP should provide a clear roadmap of the technologies, business models, users’ requirements, etc., that are being covered or are expected to be covered in the near future. This would allow the alignment of the research efforts in the standard fora and, indeed, in the different implementation efforts done by the different main vendors.

To sum up, this roadmap should let the different players (operators, vendors, regulation bodies, etc.) know when the different standards are expected.

1.3 NGN ROADMAP

According to the recommendations presented in the previous section, the specification of a roadmap to define the evolution of the NGN technologies is an important requirement to make possible the synchronized and effective evolution of the NGN as a key construct of the Future Internet.

In the scope of the EuQoS project, such a roadmap was developed considering the status of the technology in such a moment. This roadmap was presented in Callejo and Enriquez [16], and it is updated (see Figure 1.3) considering the recent developments.

Figure 1.3. NGN roadmap.

c01f003

The technology roadmap has been built considering both business and technological perspectives. In particular, the following evolution threads are considered: business models, user requirements, service plane, control plane, underlying network technologies, and operation capabilities.

Evolution Thread 1: Analysis of the Different Business Models.

The analysis of suitable business models is a must in order to define the evolution of NGN networks. It is important to clearly identify how the different stakeholders could get incentives from the different features to be developed.

In order to build the Internet of the Future with additional capabilities, it is important to understand which party will take advantage of it and how much the party is willing to pay both directly (i.e., if the customer pays directly) or indirectly (i.e., incomes coming from publicity). This would result in the specification of open interfaces requirements (from the economic point of view) and in an evolution of the current interconnection models.

Evolution Thread 2: Analysis of the End-Users’ Requirements.

As stated in the recommendations, the analysis of the end-user behavior and an estimation of their future preferences is a must for the success of the NGN. This requirement could cover multiple issues, such as security, usability of the interfaces, and so on.

Evolution Thread 3: Evolution of the Service Plane.

This evolution thread aims to analyze the features to be covered in the Service Plane of NGN. These technical features are developed according to the business models and the specification of the users’ requirements.

Important aspects to be covered here are all the issues related to the management of the user profile and the mechanisms for AAA.

Evolution Thread 4: Evolution of the Control Plane.

The mechanisms and features to be integrated and or developed for the deployment of the QoS guarantees should be analyzed. The evolution of this plane must consider operations at different timescales (i.e., for the reservation per aggregate flows and the actions to be done according to end-users’ requests).

Evolution Thread 5: Evolution of the Underlying Network Capabilities (Transport Capacities).

As far as new network technologies appear, it is important to identify when there will be solutions able to interoperate with the new network equipment and to reuse their built-in QoS mechanisms.

Moreover, in this thread, it is very important to ensure the interoperability and cooperation between different network technologies. A clear example would be the coordination between optical capabilities and the IP core routers.

Evolution Thread 6: Evolution of the OAM (Operation, Administration, and Maintenance).

OAM (Operation, Administration, and Maintenance) includes all those features that should be required in a commercial system, especially focusing on security and auditory capabilities. This is a key requirement in order to ensure the traceability of the delivery of QoS-based services.

Notes

1 Huawei, through the RM9000-Resource Manager.

2 In http://www.layer3media.com/joost/joost-network.pdf, Joost presents its architecture to provide a VoD service based on P2P systems, but at the end it is clearly stated that a possible collaboration with network providers could be beneficial in order to control the capabilities available in the last mile (that is, not under the control of the service providers).

3 In the Xbox, LIVE service could take advantage of the QoS capabilities in order to improve the end-user QoE.

4 Juniper and Cisco have recently released SDK for its operating systems.

REFERENCES

1. http://www.geni.net/.

2. http://www.nets-find.net/.

3. http://www.future-internet.eu/.

4. http://akari-project.nict.go.jp/eng/index2.htm.

5. The generation Z connection: Teaching information literacy to the newest net generation, Teacher Librarian. Available online. February 2006.

6. Cisco, Global IP traffic forecast and methodology 2006–2011, January 2008.

7. ITU-T Y.2001, General overview of NGN, December 2004.

8. ITU-T Y.2012, Functional requirements and architecture of the NGN release 1, June 2006.

9. http://www.etsi.org/tispan/.

10. http://www.3gpp.org/.

11. http://www.itu.int/en/pages/default.aspx.

12. http://www.euqos.eu/.

13. M. A. Callejo, J. Enríquez, et al., EuQoS: End-to-end QoS over heterogeneous networks, ITU-T Innovations in NGN—Future Network and Services, Geneva, pp. 177–184. May 2008.

14. X. Masip, J. Enríquez, M. A. Callejo, et al., The EuQoS system: A solution for QoS routing in heterogeneous networks. IEEE Communi. Maga., Vol. 45, pp. 96–103. February 2007.

15. D. d. Clark, J. Wroclawski, K. Sollins, and R. Braden, Tussle in cyberspace: Defining tomorrow’s Internet, SIGCOMM 2002.

16. M. A. Callejo and J. Enríquez, Bridging the standardization Gap to provide QoS in current NGN architectures, IEEE Communi. Maga., Vol. 46, pp. 132–137, October 2008.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
13.58.220.83