WO2007116411A1

WO2007116411A1 - METHOD AND APPARATUS FOR PROVISIONING ENSURED QoS TRIPLE PLAY SERVICES OVER EXISTING COPPER INFRASTRUCTURE

Info

Publication number: WO2007116411A1
Application number: PCT/IL2007/000470
Authority: WO
Inventors: Israel Fermon
Original assignee: Link Fusion Ltd.
Priority date: 2006-04-11
Filing date: 2007-04-11
Publication date: 2007-10-18
Also published as: IL174930A0

Abstract

Method and system for providing Triple Play services with assured QoS by Telecommunication companies to subscribers in MDU/MTU over existing unshielded copper infrastructure in the local loop. All the bandwidth available on the xDSL lines is aggregated to form a manageable broadband link from all or a part of the telephone lines that are routed to the building and enabled to be used as xDSL lines. The wideband services are provisioned to subscribers using the manageable broadband link, by performing statistical multiplexing and Dynamic Resource Allocation. The delivery of the multicast content such as video broadcasting is extended to reach the building and then the broadband services are distributed to each subscriber using standard based in-building distribution.

Description

METHOD AND APPARATUS FOR PROVISIONING

ENSURED QoS TRIPLE PLAY SERVICES OVER EXISTING COPPER INFRASTRUCTURE

Field of the invention

The present invention relates to the field of providing digital data and content over a data communication network. More particularly, the present invention proposes a method and apparatus for provisioning of triple play services with ensured QoS to subscribers, over existing copper infrastructure.

Background of the invention

While the delivery of combined voice and data has become widespread in the recent years, effective addition of video has been a barrier to completion of the true triple play for several reasons. First, outdated, inefficient video compression algorithms greatly exceed available bandwidth; second, bandwidth in the access networks has been insufficient for even compressed video; and third, the vast majority of today's Customer Premises Equipment (CPE) is unable to handle the service segmentation and quality of service (QoS) requirements that are crucial for voice and video services. Significant advances in video compression technology make IPTV-based video services, such as Video-On-Demand (VOD), not only practical, but highly desirable. These IPTV-based video services include improved content selection and navigation, no-delay channel changes, VOD and promotions tailored to a subscriber's viewing habits and preferences, and connection to other IP devices and content, such as photographs, music, games, or video contents located anywhere on the subscriber's network. Depending on compression technology used, each channel received from a service provider video server or distribution point needs as much as 3-4 Mb/s of bandwidth for standard definition TV (SDTV) and 9-12 Mb/s for High definition TV (HDTV). Broadcast video channels are multicast in nature. If handled properly by the network infrastructure, the amount of total bandwidth multicast video consumes between the headend (the control center of a television system, where broadcast signals are received and distributed) and RT (Remote Terminal) can be minimized. In addition, video services such as Video on Demand (VOD) are unicast in nature, i.e., requiring individual bandwidth streams from the headend to the subscriber.

A Triple Play service bundles high-speed Internet access, television (TV broadcast or Video on Demand) and telephone service over a single broadband connection. As competition between Multiple System Operators (a.k.a., Cable Operators) and Incumbent Local Exchange Carriers (ILECs) over subscribers increases, the ability to offer a Triple Play package that bundles voice, video, and data services is a dominant factor that determines the consumer's final choice. Triple Play service also allows ILECs' and CLECs to expand beyond their traditional voice services. True Triple Play services used concurrently by family members in one household require networks that can support higher quality at super-broadband speeds. They may include Point to Point like VOD (specifically requested by one person), (Point to Multipoint) like broadcasting to multiple users Television over IP, or gaming (Multipoint to Multipoint). Other services sometimes require a constant bit rate connection (like an audio stream), a bit rate that can vary within limits (like streaming video content), or a bursting data rate (like a query on a web page or file download). Solutions such as Fiber-To-The-Home (FTTH) provide the required bandwidth but require high costs (high upfront investment with long return on investment). VDSL can provide high bandwidth but is highly limited by the loop length. ADSL2 and ADSL2+ significantly boost the bandwidth, but practically cannot serve more than one TV channel and do not support the large bandwidth required for High-Definition Television (HDTV).

Fixed Wireless Access technologies like WiMax might also be able to realize the same speeds. However, the number of end-users sharing the wireless channel capacity is limited.

ADSL doesn't offer sufficient downstream bandwidth over long enough distances to be able to reach all customers. Specifically, ADSL cannot deliver 8 Mbps beyond 6,000 to 8,000 feet. Many Telco customers are 12,000 to 18,000 feet from the nearest RT. ADSL2/2+ increase ADSL bandwidth but only for shorter distances. Therefore, their effective bandwidth is limited.

VDSL provides a lot of bandwidth, but over very short distances — 3,000 to 4,000 feet and requires Fiber To The Curb (FTTC). Therefore, Telco companies are required to relocate the serving areas to approximately 4,000 feet between subscribers and RTs (the DSLAM - DSL Access Multiplexer) in order to use VDSL. This of course is costly.

All the methods described above have not yet provided satisfactory solutions to the problem of allowing Telco companies - ILECs and CLECs to provide cost effective triple play services to their subscribers, while ensuring voice and video quality.

It is therefore an object of the present invention to allow Telco companies - ILECs and CLECs providing triple play services to their subscribers, using their existing access network infrastructure, while ensuring voice and video quality.

It is another object of the present invention to allow Telco companies — ILECs and CLECs providing triple play services to their subscribers, using their existing access network infrastructure, while ensuring individual service quality and priority, especially quality-sensitive voice and video services.

It is a further object of the present invention to allow Telco companies - ILECs and CLECs providing triple play services to their subscribers, using their existing access network infrastructure, while provisioning the unique requirements of each service

It is still an object of the present invention to allow Telco companies - ILECs and CLECs providing triple play services to their subscribers, using their existing access network infrastructure, while allowing management and support of the individual services once they are provisioned.

It is yet an object of the present invention to allow Telco companies - ILECs and CLECs providing triple play services to their subscribers, using their existing access network infrastructure, in a scalable manner that does not require upfront investments. It is yet another object of the present invention to allow Telco companies - ILECs and CLECs providing triple play services to their subscribers, over existing copper lines, at High quality with no need to upgrade the existing infrastructure .

Other objects and advantages of the invention will become apparent as the description proceeds.

Summary of the invention

The present invention is directed to a method for providing broadband services (such as Triple Play services) with assured QoS by Telecommunication companies (e.g., ILECs, CLECs, Service Providers or ISPs) to subscribers in a site (e.g., - apartment buildings, office buildings, Multi Dwelling Units (MDUs), Multi Tenant Units (MTUs) or a campus deployment) over existing unshielded copper infrastructure in the local loop, according to which all the bandwidth available on the xDSL lines is aggregated to form a manageable broadband link from all or a part of the telephone lines that are routed to the site and enabled to be used as xDSL lines. The wideband services are provisioned to subscribers using the manageable broadband link, by performing statistical multiplexing and Dynamic Resource Allocation. The delivery of the multicast content (particularly video broadcasting), intended for simultaneous use by different subscribers, is extended to reach the site and then the broadband services are distributed to each subscriber using standard based in-building distribution.

Preferably, the available bandwidth on the xDSL lines is aggregated using ML-PPP protocol. In this case, whenever the ML-PPP is implemented via the U interface at the system side, the BRAS that supports ML-PPP is used as the ML-PPP termination (i.e., ML-PPP implementation at the network side) for the subscriber's data traffic. If the BRAS does not support ML-PPP or if a BRAS independent ML-PPP implementation is desired, a dedicated server is used for supporting the ML-PPP termination at the network side of the subscriber's data traffic.

Whenever the network architecture for providing broadband services complies with TR-IOl, a dedicated server that resides in the aggregation network over the V interface is used for forming a broadband ML-PPP between the V and U interfaces, based on multiple links of PPPoE. The formed broadband ML-PPP may be used for transferring data and voice. The IPTV video streaming, received by the server as an IPoE streaming, is then transferred in an appropriate protocol through the broadband ML- PPP.

The broadband services may be provisioned based on statistical multiplexing, according to different subscribers' and services' profiles at any given instance and on a corresponding dynamic resources allocation. Preferably, the multicast streaming is extended until reaching the site and then splitting the streaming via the in-building distribution.

The wideband services may be distributed among the subscribers in the site via Ethernet/LAN cables, Coax cables, Home PNA-3.0, PowerLine, using wireless communication or any combination thereof. Additional Functions like QoS Management, Resource Scheduling, Multicasting, Remote Configuration and Management, Authentication, Security, Policy Management, SLA Management, Redundancy, Admission Control, Traffic Accounting and Monitoring, Traffic Filtering, Billing Mediation, Broadcast Buffering, File Cashing or any combination thereof may also be provided along with the broadband services.

The available bandwidth on the xDSL lines may be aggregated using one of the G.998 series of ITU-T Recommendations.

The provisioning of broadband services may comply with recommendations of the DSL Forum standards and different network architectures included therein, particularly as defined in TR-25, TR-58, TR-59, TR-94 and TR-IOl.

The present invention is also directed to a system for providing broadband services with assured QoS by Telecommunication companies to subscribers in a site over existing unshielded copper infrastructure in the local loop, that comprises: a) circuitry and software for aggregating all the bandwidth available on all or a part of the telephone lines that are routed to the site and enabled to be used as xDSL lines, to form at least one manageable broadband link; b) software for performing statistical multiplexing; c) circuitry and software for performing Dynamic Resource Allocation; d) circuitry and software for extending the delivery of the multicast content intended for simultaneous use by different subscribers, particularly video broadcasting, to reach the site; and e) circuitry and software for in-building distribution of the broadband services to each subscriber.

If the available bandwidth on the xDSL lines is aggregated using ML-PPP protocol, the system includes a BRAS that supports ML-PPP as the ML- PPP termination for the subscriber's data traffic at the network side. Alternatively, the system may further include a dedicated server for supporting the ML-PPP termination at the network side of the subscriber's data traffic, whenever the BEAS does not support ML-PPP or whenever a BRAS independent ML-PPP implementation is desired. Also, a dedicated server that resides in the aggregation network over the V interface may be included, for forming a broadband ML-PPP between the V and U interfaces, whenever the network architecture for providing broadband services complies with TR-IOl.

Preferably, the system comprises circuitry and software for extending multicast streaming until reaching the site and circuitry for splitting the streaming via the in-building distribution, as well as circuitry and associated software for providing the above additional functions.

Brief Description of the Drawings

The above and other characteristics and advantages of the invention will be better understood through the following illustrative and non-limitative detailed description of preferred embodiments thereof, with reference to the appended drawings, in which:

Fig. 1 schematically illustrates the general architecture of the proposed solution, according to a preferred embodiment of the invention;

Fig. 2 schematically illustrates an exemplary concept of the proposed solution, according to a preferred embodiment of the invention;

Fig. 3 schematically illustrates the platform implemented for in- building service distribution options, according to a preferred embodiment of the invention;

Fig. 4A schematically illustrates the architecture for provisioning triple play services to subscribers with in-building distribution over existing copper infrastructure, according to a preferred embodiment of the invention; Fig. 4B schematically illustrates the architecture for provisioning triple play services to subscribers with in-building distribution over Ethernet cables, according to a preferred embodiment of the invention;

Fig. 4C schematically illustrates the architecture for provisioning triple play services to subscribers with wireless in-building distribution, according to a preferred embodiment of the invention;

Fig. 5 is a block diagram of the system for provisioning triple play services with ensured QoS to subscribers over existing copper infrastructure, according to a preferred embodiment of the invention;

Fig. 6 (prior art) schematically illustrates the process of DSL Bonding with ML-PPP;

Fig. 7A (prior art) schematically illustrates a Multi Service Reference Model taken from TR-58;

Fig. 7B (prior art) schematically illustrates a High Level Architectural Reference Model taken from TR-59;

Fig. 7C schematically illustrates the a network architecture that includes a specific server that is installed in the network to perform the BRAS functionalities related to the ML-PPP termination, according to a preferred embodiment of the invention;

Fig. 7D (prior art) depicts the network architecture considered in TR-IOl;

Fig. 8A (prior art) illustrates the protocol stacks at the U interface;

Fig. Fig. 8B (prior art) illustrates the protocol stacks at the V interface;

Fig. 9 (prior art) illustrates a common network topology when using TR-IOl; and

Fig. 10 illustrates Multi Edge network architecture, according to a preferred embodiment of the invention. Detailed description of the invention

The present invention proposes a method and system for providing residential and commercial Triple Play broadband services by Telecommunication companies (ILECs, CLECs) or service providers to apartment buildings - Multi Dwelling Units (MDU), office buildings - Multi Tenant Units (MTU), condominiums, and other campus deployments over the existing copper infrastructure.

The system proposed by the present invention combines implementation of all the functions needed to deliver these services, so as to fulfill the requirements which are essential to provide high quality Triple Play services. These requirements include: Bandwidth, QoS management, Availability and Security, in addition to other highly desirable requirements to provide efficient and profitable services. It can meet all of these requirements in a single appliance located adjacent to the Network Interface Unit (NIU/NID) - the MDF - of each building (before the Demarcation Point).

The proposed system serves as a platform that performs the following functions: Bandwidth Aggregation, Statistical Multiplexing, Resource Scheduling, Multicasting, QoS Management, In Building Distribution, Admission Control, Remote Management, Authentication, Redundancy (High Availability), Policy Management, Security, SLA Management and optionally: Traffic Accounting and Monitoring, , Traffic Filtering, Billing Mediation.

The system utilizes part or all of the existing copper twisted pair telephone lines, routed to an MDU, as bonded DSL links, while aggregating all their available bandwidth to form one "Fat Pipe". The formed broad bandwidth "Fat pipe" is than used for the provisioning of the Triple Play services based on Statistical Multiplexing, Dynamic Resource Allocation, and Multicasting. In building distribution is performed, based on Standards, such as: Home PNA3.0 or PowerLine, or LAN Cable, or Coax, or Wireless. The combination of all this functions with the way in which all the Twisted Copper Pairs routed to the building are used to achieve the required bandwidth, the dynamic allocation and the statistical multiplexing of the available resources, the Multicasting, the QoS, Policy and SLA management and the remote configuration combined with all the other functions enable Telco companies to deliver high quality Triple Play services using their existing network, maintaining and preserving their installed base of unshielded twisted pair in the local loop.

The system proposed by the present invention allows ILECs to deliver True Triple Play to Multi Dwelling Units (MDUs) over existing copper lines at High quality, without a need to replace or even upgrade the infrastructure and at a far lower cost than any other known alternative (such as FTTH, FTTCAO)SL FTTB/VDSL etc.). ILECs can provide multi-channel TV, HDTV, VOD, ultra-high-speed data and VoIP over their existing installed base of unshielded twisted pairs in the local loop.

In order to deliver commercial Triple Play services acceptable Quality of Service requirements must be met. By deploying such highly integrated systems, service providers can expand their offerings easily and cost effectively, better manage and control traffic, and accelerate the delivery of triple play services. The end result is a quicker time to market and an assured user experience of Triple Play services over the existing copper infrastructure. The proposed platform performs the following functions: Bandwidth Aggregation, Statistical Multiplexing, Resource Scheduling, Multicasting, QoS Management, In Building Distribution, Admission Control, Remote Management, Authentication, Redundancy (High Availability), Policy Management, Security, SLA Management and optionally: Traffic Accounting and Monitoring, , Traffic Filtering, Billing Mediation.

Fig. 1 schematically illustrates the general architecture of the proposed solution, according to a preferred embodiment of the invention. The system 10 that is installed in the building aggregates the bandwidth of all incoming DSL lines into a wideband link and it's bandwidth is then dynamically allocated.

Fig. 2 schematically illustrates the concept of the proposed solution, according to a preferred embodiment of the invention. The incoming lines may be ADSL lines, ADSL2 lines, and ADSL2+ lines or a combination of these lines.

System 10 performs bandwidth aggregation from all incoming lines. For a building consisting of n apartments there are at least n telephone lines (copper twisted pairs) already installed by the Telco company (ILEC) in order to provide Plain Old Telephone Service (POTS). These n lines terminate in a Network Interface Unit or Device (NIU/NID) the MDF in the building. From the MDF cabinet, each copper pair is routed to an apartment and terminated by a telephone set.

Each telephone line can be enabled to be a DSL line to carry digital data, in addition to the circuit switch telephone voice. DSL is a family of technologies that provide digital data transmission over the wires used in the "last mile" of a local telephone network. The most common DSL technology is ADSL. ADSL standard can (theoretically) deliver 8 Mbit/s over about 2 km (VA miles) of unshielded twisted pair copper wire. All the available bandwidth is aggregated from all or part of the lines rolled out to the building as DSL enabled links, into one broad manageable link of a bandwidth equal to n times each DSL line bandwidth. Several known techniques may be used to implement the bandwidth aggregation (these techniques are sometimes called "Loop Bonding") and will be described below.

After the DSL loops have been bonded, the resultant aggregated link is used for the provisioning of the wideband services, including true Triple Play, to the various customers in the building based on Statistical Multiplexing and Dynamic Resource Allocation. In this manner, the required bandwidth for such service can be achieved based on the following logical assumptions:

• first, not all households are necessarily customers of the service.

• second, not all users use the service simultaneously

• third, not all connected users consume the same service concomitantly (Web browsing, file downloading, watching TV broadcast, VoIP conversation, etc.) .

• fourth, part of the data is delivered in bursts;

• fifth: the managed resources are allocated to subscribers dynamically.

The system proposed by the present invention can save bandwidth also when video content is delivered by multicasting. Multicast is the delivery of video streams (video broadcast channels) to a group of destinations simultaneously using the most efficient strategy to deliver the video streams over each link of the network only once, creating copies only when the links to the destinations split. Significant part of the traffic is expected to be IPTV broadcast. During multicasting, only one stream is required for multiple audience of the same broadcast. Usually Multicast is brought all the way from the video server, located at the service provider to the DSL aggregation point (the DSLAM- DSL Access Multiplexer) and then is split to each individual subscriber. System 10 extends the multicasting to the MDU, while splitting the streams through the "In Building Distribution" as described below. This saves precious bandwidth in the last mile, which is the most critical part and bottle neck of the network - the access network.

The proposed system is located adjacent to the building MDF, as shown in Fig. 4A. In building service distribution to each apartment, as shown in Fig. 3 is implemented based on one of the following methods: LAN cable — CAT5; Coax; HPNA 3.0 standard; PowerLine; Wireless.

Service Example

The following service example describes an MDU of a building with 50 apartments. There are at least 50 telephone lines which can be used as DSL enabled links, Either ADSL ADSL2 ADSL2+ or any combination of them. It is assumed that the service provider has a relatively high penetration level of 40%, i.e., the service provider has 20 subscribers (customers) in this building. It is also assumed that only 36 copper lines (out of the 50 available) are used as ADSL links. Each link provides 5Mb/s data rate (for short enough loop length the standard can reach 8Mb/s). After bonding all these links and aggregating all the available bandwidth, system 10 forms one broad pipe of (36x5) 180Mb/s, as shown in Table I. If more bandwidth is needed more links can be added to the "pipe" (the 50-36=14 unused lines) and if and when ADSL2/2+ will be available, broader bandwidth pipes can be formed by simply reconfiguring system 10. Table I

The following example describes a service scenario for such MDU in a typical demand. In this example 43 users (at the 20 households which are subscribers of the wideband service) are served as follows:

17 users are watching 6 High Definition TV broadcast channels. 5 users are watching 2 Standard Definition TV broadcast channels. 2 users are watching High Definition Video on Demand. 5 users are making VoIP calls 10 users are surfing the Web.

To provide this service demand a total bandwidth of 109Mb/s is required out of the 180Mb/s available, as shown in Table II.

Table II

The following additional example describes a service scenario for such MDU in an extreme demand. In this example, 67 users (at the 20 households which are subscribers of the wideband service) are served as follows:

24 users are watching 6 High Definition TV broadcast channels. 5 users are watching 2 standard Definition TV broadcast channels. 4 users are watching High Definition Video on Demand. 15 users are making VoIP calls 20 users are surfing the Web.

To provide this service demand a total bandwidth of 140Mb/s is required out of the 180Mb/s available, as shown in Table III.

Table III

It is assumed that 12Mb/s is required for HDTV channel though 9-10Mb/s is sufficient for MPEG4. There is still additional 40Mb/b margin left to fulfill even higher demand. For even more extreme cases there are still (50-36) 14 more unused lines that can be added by the service provider as required to provide for additional (5x14) 70Mb/s to this particular MDU. For even more extreme cases, (which are very rare with extremely low probability to happen), exceeding the available resources, the "Admission Control" (see below) comes into action according to its algorithms and the service provider policy.

Other requirements essential for the successful delivery of the service are also fulfilled by system 10, which functions as a platform, on which all these requirements are met while providing prominent advantages.

The platform implemented by system 10 is located adjacent to the building MDF, as shown in Fig. 3. In building service distribution to each apartment is implemented based on one of the following methods: LAN cable - CAT5; Coax; HPNA 3.0 standard; PowerLine; Wireless. The terminal devices that may consume the broadband service may include a PC 301, a home server 302, a TV STB 303, a PDA 304, a gaming console 305, a VOIP phone 306, a security camera 307 or a Home Network sharing device 308.

Fig. 4A schematically illustrates the architecture for provisioning triple play services to subscribers with in-building distribution over existing copper infrastructure, according to a preferred embodiment of the invention.

Fig. 4B schematically illustrates the architecture for provisioning triple play services to subscribers with in-building distribution over Ethernet cables, according to a preferred embodiment of the invention.

Fig. 4C schematically illustrates the architecture for provisioning triple play services to subscribers with wireless in-building distribution, according to a preferred embodiment of the invention.

Fig. 5 is a block Diagram of the system for provisioning triple play services with ensured QoS to subscribers over existing copper infrastructure, according to a preferred embodiment of the invention.

System 10 provides the required bandwidth by combining the traditional copper telephone lines, used for DSL, to form one broad, manageable data pipe. This is accomplished by one of the following ways:

Several DSL Forum protocol models for accessing data networks utilize the Point-to-Point Protocol (PPP) to carry packets over the "U" interface (described with respect to Figs. 7A to 7C below). Because of the widespread use of PPP, Multi Link PPP (ML-PPP) can be used for DSL Bonding. ML- PPP as defined in RFC 1990 can be used to combine multiple PPP links into a single virtual bundle. At the transmitting side, ML-PPP takes a PPP packet, optionally fragments it and generates a new ML-PPP header. Each resulting fragment (or a whole packet) is transmitted across a separate physical link. At the receiving side, the per-fragment headers are used to reconstruct the complete packets. This process is represented schematically in Fig. 6.

The Multi Link PPP (MLPPP) protocol has the following advantages regarding DSL link bandwidth aggregation method (DSL bonding):

• Standard well known widely used protocol

• Capable of asymmetric operation over ADSL, ADSL2, ADSL2+ and VDSL

• Allows routing of delay sensitive traffic over a single link via PPP, bypassing the ML-PPP bundle and an associated delay in ML-PPP processing

• When implemented with multi-class extensions, provides additional support for traffic of different priorities or classes.

• Provides the flexibility to the distribution of fragments to links and therefore, freedom to accommodate links of different bandwidth, thereby supporting dynamic link rate changes.

The proposed solution fully complies with recommendations of the DSL Forum standards, in particular as defined in the following Technical Reports (TRs):

• TR-25 - Core Network Architecture Recommendations for Access to Legacy Data Networks over ADSL

• TR-58 - Multi-Service Architecture & Framework Requirements

• TR-59 - DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services • TR-94 - Multi-Service Delivery Framework for Home Networks

• TR-IOl - Migration to Ethernet-Based DSL Aggregation

Fig. 7A (prior art) schematically illustrates a Multi Service Reference Model taken from TR-58.

Fig. 7B (prior art) schematically illustrates a High Level Architectural Reference Model taken from TR-59.

The ML-PPP is implemented via the U interface at the system side (The U interface protocol stacks are specified below).

At the network side, The ML-PPP is implemented at the Broadband Remote Access Server (BRAS). The BRAS is the aggregation point for the subscriber's data traffic. It provides aggregation capabilities (e.g., IP, PPP, ATM) between the Regional/Access Network and the NSP or ASP. In addition to aggregation, it is also the "injection point" for policy management and IP QoS in the Regional/Access Networks.

Commercial BRAS implementations can support the MLPPP protocol. All is needed in this case at the network side for the above network architecture is to configure the BRAS for MLPPP. Thus, system 10 in this case is single sided single box solution that does not require any changes in the network topology (except BRAS configuration for ML-PPP).

There might be cases in which ML-PPP configuration in the BRAS is not possible or is not desirable or cases in which an independent solution or system testing is desirable. For such cases, a specific server 701 can be installed in the network to perform the BRAS functionalities related to the ML-PPP implementation, as depicted in Fig. 1C. This solution is carried out by software and there is no need for the BRAS to support ML-PPP.

DSL Forum TR-IOl outlines how an ATM aggregation network can be migrated to an Ethernet based aggregation network in the context of TR-25 and TR-59 based architectures. The TR-101 provides an architectural/topological model of such an Ethernet based aggregation network that supports the business requirements in TR-058. It describes requirements for protocol translation and interworking, QoS, multicast, security, and OAM for a DSL aggregation network.

TR-101 defines a new access network topology where the connectivity between the Access Node and the Broadband Network Gateway is Ethernet based rather than ATM. Access nodes can be directly connected or can go through an aggregation layer(s) before reaching the Broadband Network Gateway.

TR-059 based architectures assume a single Broadband Network Gateway (e.g., BRAS) where user services are performed. TR-101, however, recognizes the potential for service segregation. Some applications, such as video, may have specific enough requirements from the network that they are best optimized separately from other types of traffic. The architecture described in TR-101 supports the possibility for a dual Broadband Network Gateway (BNG) scenario when required for video optimization. When used, the BNG dedicated to video is denoted as the 'video BNG'. Such an approach may have additional complexities not present with a single BRAS/BNG arrangement described in TR-059. This is most notable with respect to traffic/bandwidth management and the resulting network efficiency, as well as the additional operations overhead. Furthermore, in dual node architectures, it is not mandated that both BNGs support all of the requirements detailed in TR-IOl. Specifically, the video BNG may not implement subscriber management functions (e.g., PPP termination, per user QoS), provided that these functions are likely to be performed by the other BNG. Fig. 7D (prior art) depicts the network architecture considered in TR-IOl. The fundamental changes from current deployment architectures are:

• V interface that supports Ethernet as the transport protocol with no ATM present.

• An Ethernet aggregation network

• The possibility of dual Broadband Network Gateways

• Higher bit rate services (e.g. by supporting Access Nodes nearer the end-user)

• Higher network availability (in support of application and business customer needs)

• U interface that could support direct Ethernet framing over DSL.

Similar to the TR-059 architecture, the architecture depicted in Fig. 7D uses a Broadband Network Gateway for providing IP QoS down to the user level. TR-059 also supported legacy ATM services that may not have traversed the BNG. Similarly, the architecture described within this document (TR-IOl) also enables services to be injected into the network without going through a single Broadband Network Gateway.

Fig. 8A (prior art) illustrates the protocol stacks at the U interface.

Option 'a' is denoted IPoEoATM and option V is denoted PPPoEoATM.

Option 'c' is denoted IPoA and option 'd' is denoted PPPoA. Options 'e' and 'f represent those scenarios when the access loop supports direct Ethernet encapsulation and are referred to as IPoE and PPPoE.

Similarly, Option 'g' represents a pure Ethernet service where there is no visibility above layer 2. Both options 'a' and V are commonly referred to as IPoE and options 'b' and 'f ' are referred to as PPPoE.

Those options where Ethernet is included in the protocol stack may also include 802. IQ headers to carry Virtual LAN (VLAN) tags and priority markings.

The PPP is the protocol that allows the carriers to connect the customers to different ISP's/CSP's and allow them to authenticate the customers via Remote Authentication Dial-In User Service (RADIUS) protocol and provide them with the services they are paying for through Lightweight Directory Access Protocol (LDAP) database in the back office.

Fig. 8B (prior art) illustrates the protocol stacks at the V interface.

DSL Forum's TR-IOl defines the network topologies for supporting multiple services using Ethernet networks. Unlike its predecessor, TR-IOl does not mandate a single topology but rather allows several variations. One new alternative is support for IP over Ethernet (IPoE) encapsulation. IPoE extends several LAN-based protocols, including Dynamic Host Configuration Protocol (DHCP, which is a communications protocol that lets network administrators centrally manage and automate the assignment of Internet Protocol (IP) addresses in an organization's network) to allow using a broadband network.

Fig. 9 (prior art) illustrates a common network topology when using TR- 101. TR-IOl does not advocate using IPoE over PPPoE, but rather allows the broadband provider to select when to use each alternative. Since DHCP was designed for use on a shared LAN, its capabilities complies with the requirements for sending common data traffic to many users. Traditional broadcast television is an example of this case. As a result, IPoE/DHCP is typically used for delivering IPTV data traffic. In contrast, PPPoE more closely meets the needs of point-to-point broadband connections such as data and VoIP, since it was designed to support this environment. Broadband networks have been using PPP for many years, while DHCP is a recent entrant into this market. Today, existing unicast services are offered using PPP and there is little impetus to move away from using it. In fact, many broadband service providers prefer to stick with PPPoE, since it is more functional and mature than IPoE/DHCP, eliminates the need to retrain operations personnel, and lowers the risk of adding new subscribers and services. The most common broadband implementation, therefore, is to use IPoE/DHCP to support TV and other services across the broadband network to the Set-Top-Box (STB, which is a device that converts signals to be viewable images on TV), while using PPPoE to support services to other devices such as PCs and VoIP phones. Businesses receive all broadband services typically via PPP while residential subscribers receive services via both technologies.

The solution proposed by the present invention can also be adjusted to be used by multiple edge routers. Many organizations would like to use the same simple edge switch and DSLAM access networks, but manage the services separately in the metro network using different edge routers. This is most common if another organization (either another group within the same broadband service provider or a contracted third party) provides the IP video services. This scenario is depicted in Fig. 9. Fig. 10 illustrates a Multi Edge Network architecture, according to a preferred embodiment of the invention. At the side of system 10, the architecture is similar to all other cases. At the network side, one or more servers 101 are installed in the Aggregation Network. The higher in the aggregation hierarchy the less servers are needed per DSLAMs served by each server 101 (thereby reducing the system per subscriber cost, at the expense of less redundancy).

The server 101 is configured to create ML-PPP data pipe between system 10 (at the U interface) and server 101 (at the V interface). Such a data pipe is created per each system 10 in the network. In addition, server 101 receives the IPTV streaming video reaching it as IPoE, and transfers it to the respective destination in an appropriate protocol through ML-PPP data pipe, in addition to the VoIP and the data traffic.

When building an IPTV-capable broadband network, one important issue is VLAN design. VLANs limit the broadcast domain, potentially ensuring that subscribers cannot see each other's information and reducing network traffic. VLANs allow the network to logically segment the network into multiple communities by "tagging" each packet with a field which identifies packet ownership. VLAN usage is standardized as IEEE 802.1Q, and are sometimes called "VLAN tags" or "Q-tags". There are two fundamental VLAN design options:

1. Customer VLAN: In this model, there is a dedicated VLAN for each subscriber. This is also called the 1:1 model since there is one VLAN per subscriber.

2. Service VLAN: In this model, there is a dedicated VLAN for each service. This is also called the N:l model since multiple subscribers share each

VLAN. System 10 can be adopted for each of the two fundamental VLAN design options.

In addition, system 10 can be configured to support other possible Loop bonding techniques that are used to implement DSL bonding according to the G.998 series of ITU-T Recommendations, which simply increases the data rate in proportion to the number of bonded lines. Two bonded lines will double the data rate for both upstream and downstream. Likewise three bonded lines will triple the data upstream and downstream rate, and so on. This is independent of the DSL technology (ADSL, VDSL etc.). The following three different types of bonding offer multiplexing of various service data streams (Ethernet, ATM, TDM) over multiple DSL links:

Recommendation G.998.1 ATM-based multi-pair bonding' describes a method for bonding of multiple digital subscriber lines (DSL) to transport an ATM payload beyond the rate/reach capability of a single DSL loop.

The bonding protocol allows the bonding of 2-32 loops (copper wire pairs) and supports dynamic removal and restoration of pairs without human intervention. The maximum one-way bonding delay will not exceed 2 ms.

Recommendation G.998.2 Εthernet-based multi-pair bonding' describes a method for bonding of multiple digital subscriber lines (DSL) for Ethernet transport. This Recommendation builds on the IEEE 802.3ah-2004 methods and extends Ethernet transport over other xDSL technologies, including ADSL.

Recommendation G.998.3 'multi-pair bonding using time-division inverse multiplexing' describes a method for bonding of multiple Digital Subscriber Lines (DSLs) using Time-Division Inverse Multiplexing (TDIM). This Recommendation uses IEEE 802.3ah handshake for pair discovery, parameter negotiation and setup. It allows the hitless addition and removal of pairs and the fast removal of a pair upon pair failure.

In addition to bandwidth aggregation and dynamic resource allocation, system 10 is configured to provide Quality of Service (QoS) management. The QoS implementation allows delivery of high-priority video and premium data traffic. The use of hierarchical scheduling for QoS allows bandwidth management between requests for a single end user and controlled bandwidth distribution between different user types.

When sharing network resources with other services, most services also needs some form of 'Quality of Service', in order to ensure the quality of the service can be what the end-user expects. Requirements on the network to support Quality of Service differ from service to service. For example a telephony service will have more stringent quality of service requirements then a more 'general' Internet access service (browsing websites). Usually the following "Quality of Service parameters" are used to express how the network can support a certain quality to a service (telephony, video, or internet):

Delay/Delay Variations (Jitter): Services that have to be delivered almost 'real-time' (like the VoIP telephony service) often have more stringent requirements regarding the delay and variation in delay than non Real-Time services (like file downloads). A VOD service is less susceptible to delay, since often the video stream is 'buffered' for several seconds in the player in order to be able to adjust hick-ups in the network.

Packet Loss: A low packet loss is usually more important for services that cannot retransmit their information when it was in error. This is the case with most of the 'real-time' services which do not have the time to do this (if they retransmit an erroneous packet the retransmission will come most likely to late to use, since that video or audio segment has already passed). In order to make sure that delay (variation) and packet loss requirements can be fulfilled for specific traffic flows under network congestion conditions, system 10 implements "Quality of Service mechanisms". These mechanisms consist of implementing the tagging (marking) of certain types of traffic (e.g. voice- or internet-traffic) and using this to serve e.g., voice traffic with a higher priority than the internet traffic (which has to wait a bit longer than the voice-traffic to be transmitted).

The traditional packet scheduling mechanism on the Internet has been first-in, first-out (FIFO) scheduling, by which packets are transmitted in the same order in which they arrive in the output queue. FIFO is simple and easy to implement but cannot differentiate between multiple data flows; hence, FIFO cannot allocate specific performance bounds for a flow, or prioritize one flow over the others.

Weighted Fair Queuing (WFQ) is a scheduling discipline, according to which flow differentiation occurs in scheduling. In WFQ, each flow or traffic class is assigned a weight, and the rate at which a flow or a traffic class is serviced is proportional to its assigned weight. WFQ provides prioritization among unequally weighted traffic flows and fairness and protection among equally weighted traffic flows as per the max-min fair-share allocation scheme.

Packet dynamics in a network can make the network prone to occasional or constant congestion. At times when a network doesn't see traffic congestion, any scheduling scheme works, because no queues build. When some network congestion exists, however, queues build upon, and the scheduling mechanism determines the order in which the packets in the queue are serviced.

For the scheduling algorithm to deliver QoS, at a minimum it needs to be able to differentiate among the different packets in the queue and know each packet's service level. Such a scheduling algorithm should allow guarantees on performance bounds by allocating resources on a flow basis and/or by prioritizing one flow over the other. In addition, a scheduling algorithm is needed that provides fairness and protection among the flows with the same priority, such as all best-effort traffic flows.

Security in general is important for services that carry some privacy sensitive information (like the content of a telephone conversation or home banking), or content that has a certain commercial value (like on demand movies). These services need some level of protection so that only the intended recipient can receive and use this information. This type of security is usually implemented on a 'higher level' than by the network itself, often this is done by the (service related) client and server (like a software player or set top box for the on demand video). Network level security consists of more general security functions like some sort of "traffic separation" between different users by means of port based traffic switching or Virtual LANs and/or the possibility to 'bulk encrypt" all the traffic between user and central office. The segregation of traffic function is often used to make sure that traffic of customers served by one Service Provider do not interfere with the traffic generated by customers of a different Service Provider and is especially important for "open broadband networks" which give access to multiple Service Providers.

Most current internet-based services have low availability requirements as they are often free of charge and do not perform 'critical' services. However, this situation is changing as the existing services such as telephony and broadcast TV will also be offered over the Internet (Voice over IP, Digital TV over IP) via the different types of broadband networks. For these services often the user will have to pay a fee and has an expectation that the availability is similar as the service that was offered in the 'traditional' way. The uninterrupted availability and reliability is provided by system 10 using its built-in redundancy.

Policy management allows operators to establish subscriber and service parameters that dynamically provide access to a choice of service levels, as well as a mechanism to better manage and bill for these services. System 10 supports dynamic, network control, according to policy, thereby helping service providers to deliver highly customized business and consumer broadband services while reducing total cost of network ownership. Policies can be created to account for a wide range of user and service attributes, such as user identity, user location, user service level, time of day, available network resources, or network-use restrictions.

In order to provide any predictability or guarantee for transport QoS, there must be some end-to-end control of how much traffic is allowed into each IP QoS service class. Even a strict priority queue does not provide guaranteed service if too much traffic is entered into it. This is why resource based admission control is required. The ability to deny a session by means of admission control is a powerful tool for the service provider. Some of the benefits provided are:

If there are n sessions in a service and session n+1 is denied, based on resource based admission control, the quality of the n established sessions is consistently protected. If an additional session n+1 is admitted, the service provider would risk facing n+1 unsatisfied subscribers who pay a premium fee for a guaranteed QoS service which in essence, is being degraded by faulty admissions.

Resource based admission control relates to bandwidth management (as bandwidth is the resource being controlled). An admission control function should combine policy based and resource based admission control. There can be a range of non-resource based policies in place to support sophisticated business models of the service provider. Admission control decisions are combined policy based and resource based decisions.

System 10 can significantly reduce service providers' operational expenses by enabling automatic connection, configuration, and provisioning of initial broadband services, as well as allowing subscriber self-provisioning for adding new services or changing existing services once they have become a broadband customer. It allows provider staff at a central location to manage quality-sensitive triple play services such as VoIP and video. It automates a variety of tasks, thereby saving significant amounts of human hours, including management of: centralized Virtual Private Network (VPN, which is a network that uses a public telecommunication infrastructure, such as the Internet, to provide remote offices or individual users with secure access to their organization's network), firewall, firmware, and configuration administration, real time single-device management and automated tasks for mass CPE, new service provision and integration with provider billing systems.

System 10 simplifies provisioning and management of all IP -based services and devices at the customer premises for reduced errors and lower operational costs.

System 10 can also deliver differentiated service levels to different classes of subscribers and price them accordingly based on SLA, e.g., premium service or service packages.

System 10 can (optionally) monitor filter and prevent or block users' access to unsuitable content. When the filter is activated, users cannot open or link to sites that the filtering rules recognize as unsuitable, (e.g., pornographic sites). Filtering of incoming and outgoing email can also be provided. Since different groups of users may require different filtering, System 10 enables the tailoring of individual subscriber's requirements. System 10 can also manage attempted access to blocked resources or emails containing inappropriate language or material. For example, if a keyword matching/blocking algorithm identifies a match, it might either not display the offending page or email at all or display it but with the offending content obscured or stripped out.

IP traffic accounting and network monitoring makes it easy to count custom IP packets and troubleshoot problems saving network administration efforts. It captures all, but count only useful data. It creates counting rules for a single host, for a subnet, for a specific group of hosts, it supports a traffic accounting per any IP protocol with splitting traffic per port numbers. It allows real-time visualization of traffic activity on graphic charts. The traffic counters or the custom packet headers can be stored in a database, thereby providing the ability to build various traffic reports or traffic traces per month or/and per day.

System 10 can also provide authentication services that are required for authorizing a service provider administrator to access all the remote configuration functions as described above. In addition authentication is required to let authorized subscribers to access data which is relevant to them.

Since software can generate traffic volume statistics based on the number and origin of the records passing through it, those statistics could then be used for capacity planning or as part of a network monitoring procedure, as well as Billing Mediation, used to convert one type of data to another, for billing purposes. It is used to process IP Detail Record (IPDR) which provides information about IP-based service usage Video streaming applications typically employ large buffers (between 30 seconds and several minutes) at the receiving end. This helps avoiding any delay, jitter or packet loss. As long as the required bandwidth is guaranteed, the receiving application should be able to effectively deal with any other QoS requirements. System 10 can provide file cashing, so as to obtain more efficient access to frequently-visited Internet pages by holding them in local memory.

The above examples and description have of course been provided only for the purpose of illustration, and are not intended to limit the invention in any way. As will be appreciated by the skilled person, the invention can be carried out in a great variety of ways, employing more than one technique from those described above, all without exceeding the scope of the invention.

Claims

Claims:

1. Method for providing broadband services with assured QoS by Telecommunication companies to subscribers in a site over existing unshielded copper infrastructure in the local loop, comprising: a) forming at least one manageable broadband link from all or a part of the telephone lines that are routed to said site and enabled to be used as xDSL lines, by aggregating all the bandwidth available on said xDSL lines; b) provisioning said wideband services using said manageable broadband link to subscribers, by performing: b.l) statistical multiplexing; b.2) Dynamic Resource Allocation; c) extending the delivery of the multicast content intended for simultaneous use by different subscribers, particularly video broadcasting, to reach said site; and d) performing in-building distribution of said broadband services to each subscriber.

2. Method according to claim 1, wherein the broadband services include Triple Play.

3. Method according to claim 1, wherein the site is selected from the following group:

- apartment buildings;

- office buildings;

- Multi Dwelling Units (MDUs);

- Multi Tenant Units (MTUs);

- a campus deployment.

4. Method according to claim 1, wherein telecommunication companies include:

- ILECs;

- CLECs;

- Service Providers; - ISPs

5. Method according to claim 1, wherein the available bandwidth on the xDSL lines is aggregated using ML-PPP protocol.

6. Method according to claim 5, wherein whenever the ML-PPP is implemented via the U interface at the system side, the BRAS that supports MIJ-PPP is used as the ML-PPP termination for the subscriber's data traffic at the network side.

7. Method according to claim 6, wherein whenever the BRAS does not support ML-PPP or whenever a BRAS independent ML-PPP implementation is desired, a dedicated server is used for supporting the ML-PPP termination at the network side of the subscriber's data traffic.

8. Method according to claim 5, wherein whenever the network architecture for providing broadband services complies with TR-IOl, a dedicated server residing in the aggregation network over the V interface is used for forming a broadband ML-PPP between the V and U interfaces, based on multiple links of PPPoE.

9. Method according to claim 8, wherein the formed broadband ML-PPP is used for transferring data and voice.

10. Method according to claim 8, wherein the formed broadband ML-PPP is used for receiving the IPTV video streaming based on IPoE and for transferring the video streaming in an appropriate protocol over said broadband ML-PPP.

11. Method according to claim 1, wherein the broadband services are provisioned based on statistical multiplexing, according to different subscribers' and services' profiles at any given instance and on a corresponding dynamic resources allocation.

12. Method according to claim 1, wherein multicast streaming is extended until reaching the site and then splitting said streaming via the in-building distribution.

13. Method according to claim 1, wherein the wideband services are distributed among the subscribers in the site via one of the following means:

- Ethernet/LAN cables;

- Coax cable; Jigme PNA-3.0

- PowerLine;

- wireless communication; or

- any combination thereof.

14. Method according to claim 1, further comprising providing one or more of the following functions along with the broadband services:

- QoS Management; - Resource Scheduling;

- Multicasting;

- Remote Configuration and Management;

- Authentication;

- Security;

- Policy Management;

- SLA Management;

- Redundancy;

- Admission Control;

- Traffic Accounting and Monitoring;

- Traffic Filtering;

- Billing Mediation;

- Broadcast Buffering;

- File Cashing; and

- any combination thereof.

15. Method according to claim 1, wherein the available bandwidth on the xDSL lines is aggregated using one of the G.998 series of ITU-T Recommendations .

16. Method according to claim 1, wherein the provisioning of broadband services complies with recommendations of the DSL Forum standards and different network architectures included therein, particularly as defined in the following Technical Reports (TRs):

- TR-25;

- TR-58;

- TR-59; - TR-94;

- TR-IOl

17. System for providing broadband services with assured QoS by Telecommunication companies to subscribers in a site over existing unshielded copper infrastructure in the local loop, comprising: a) circuitry and software for aggregating all the bandwidth available on all or a part of the telephone lines that are routed to said site and enabled to be used as xDSL lines, to form at least one manageable broadband link; b) software for performing statistical multiplexing; c) circuitry and software for performing Dynamic Resource Allocation; d) circuitry and software for extending the delivery of the multicast content intended for simultaneous use by different subscribers, particularly video broadcasting, to reach said site; and e) circuitry and software for in-building distribution of said broadband services to each subscriber.

18. System according to claim 17, in which the broadband services include Triple Play.

19. System according to claim 17, in which the site is selected from the following group:

- apartment buildings;

- office buildings;

- Multi Dwelling Units (MDUs);

- Multi Tenant Units (MTUs);

- a campus deployment.

20. System according to claim 17, in which the telecommunication companies include:

- ILECs;

- CLECs;

- Service Providers; - ISPs

21. System according to claim 17, in which the available bandwidth on the xDSL lines is aggregated using ML-PPP protocol.

22. System according to claim 21, including a BRAS that supports ML-PPP as the ML-PPP termination for the subscriber's data traffic at the network side.

23. System according to claim 22, further including a dedicated server for supporting the ML-PPP termination at the network side of the subscriber's data traffic, whenever the BRAS does not support ML-PPP or whenever a BRAS independent ML-PPP implementation is desired.

24. System according to claim 21, further including a dedicated server that resides in the aggregation network over the V interface, for forming a broadband ML-PPP between the V and U interfaces, whenever the network architecture for providing broadband services complies with TR-IOl.

25. System according to claim 17, comprising circuitry and software for extending multicast streaming until reaching the site and circuitry for splitting said streaming via the in-building distribution.

26. System according to claim 17, in which the wideband services are distributed among the subscribers in the site via one of the following means:

- Ethernet/LAN cables;

- Coax cable;

- Home PNA-3.0

- PowerLine;

- wireless communication; or

- any combination thereof.

27. System according to claim 17, further comprising circuitry and associated software for providing one or more of the following functions along with the broadband services:

- QoS Management;

- Resource Scheduling;

- Multicasting;

- Remote Configuration and Management;

- Authentication;

- Security;

- Policy Management;

- SLA Management;

- Redundancy;

- Admission Control;

- Traffic Accounting and Monitoring;

- Traffic Filtering;

- Billing Mediation;

- Broadcast Buffering; - File Cashing; and

- any combination thereof.

28. System according to claim 17, in which the available bandwidth on the xDSL lines is aggregated using one of the G.998 series of ITU-T Recommendations .

29. System according to claim 17, in which the provisioning of broadband services complies with recommendations of the DSL Forum standards and different network architectures included therein, particularly as defined in the following Technical Reports (TRs):

- TR-25;

- TR-58;

- TR-59;

- TR-94;

- TR-101