WO2008119813A1

WO2008119813A1 - Method and device for limiting a number of multicast channels

Info

Publication number: WO2008119813A1
Application number: PCT/EP2008/053914
Authority: WO
Inventors: Jorge Luis Veiga
Original assignee: Nokia Siemens Networks Oy
Priority date: 2007-04-02
Filing date: 2008-04-02
Publication date: 2008-10-09

Abstract

A method and a device are provided for limiting a number of multicast channels over at least one access line according to at least one information associated with a subscriber. The information may relate to static information, such as the number of allowed channels, dynamic information, such as available bandwidth for multicast or the quality of the link or priority information for the multicast channel.

Description

METHOD AND DEVICE FOR LIMITING A NUMBER OF MULTICAST CHANNELS

The invention relates to a method and a device for limiting a number of simultaneous multicast channels and a communication system comprising such a device.

Multicast services are getting ubiquitous and important in both residential and business areas. Services like Video Mul^¬ ticast, Video on Demand and Radio multicast are available and may be used by ADSL2+ or VDSL2 technologies, which allow downstream bandwidths of up to 100 Mbps . In addition, busi- ness customers having access to Ethernet connections with rates of 1 or 10 Gigabit/s, video conference services can be used in excellent video and audio quality. Even surveillance systems for security issues may use this kind of technology.

The overall available bandwidth is also increasing with re^¬ gard to the private consumer: For example, a customer can subscribe for receiving multiple multicast channels (e.g., radio, video channels or other control data) simultaneously. These channels are transmitted together with other type of traffic (e.g., data traffic) via the same interface.

However, the maximum available bandwidth per access line is limited.

US 2005/0041680 Al describes how to physically limit the num^¬ ber of simultaneous multicast channels to be conveyed across an access line.

However, this approach still bears the disadvantage that only the absolute maximum number of multicast channels is re^¬ stricted in order to ensure fairness between ports, i.e. ex^¬ isting users of a multicast service. The object to be solved is to overcome the disadvantages stated supra and hence to provide a more flexible approach administering a number of multicast ports and/or users ac^¬ cessing multicast service over at least one access line.

This problem is solved according to the features of the inde^¬ pendent claims. Further embodiments result from the depending claims .

In order to overcome this problem a method is provided for limiting a number of multicast channels over at least one ac^¬ cess line according to at least one information associated with a subscriber or with the channel properties, e.g., an associated measured statistical bandwidth.

The number of multicast channels may refer to a number of channels sent or made available simultaneously over at least one (logical or physical) access line.

The subscriber may be a user, a consumer or a customer of a multicast service. The multicast service may contain user data, e.g., video data and audio data.

It is an embodiment that the at least one information com- prises static information, dynamic information and/or priority information associated with at least one multicast chan^¬ nel .

In a further embodiment, the static information comprises: - A referential bandwidth;

- A static condition of the at least one access line;

- An amount of multicast traffic allowed on the at least one access line.

According to the referential bandwidth, a certain threshold of bandwidth allocated by a particular subscriber may be determined. Further, a static condition of the at least one ac^¬ cess line may influence the information used for limiting the number of multicast channels for a particular subscriber. Also, multicast traffic may be regarded in order to determine whether a particular subscriber should be entitled to obtain a further multicast channel. The static information as well as the dynamic information may relate to a pricing of the multicast channels, e.g., the more expensive a particular subscription to multicast channels, the more channels will be provided for this subscriber.

It is also an embodiment, that the dynamic information com- prises a dynamic condition of the at least one access line in particular subsequent to a quality of service (QoS) model. Such quality of service (QoS) model may comprise one of the following:

- A bit error rate (BER) ; - receivedErroredPackects / receivedPackets;

- frameCheckSequenceErrors / frameCheckSequenceRe- ceived;

- lossOfSynch;

- unavailable seconds; - severely errored seconds.

It is to be noted that further quality of service parameters could be considered.

A dynamic condition of different multicast channels like a respective statistical bandwidth can be measured, e.g., at an upper link port of a network node (if supported) .

The dynamic condition of the at least one access line may de- pend on the quality of a physical connection. Monitoring pa^¬ rameters of QoS like BER may allow to determine the overall port budget for multicast channels to be provided.

In order to determine as how the number of multicast channels shall be limited, it is also possible to determine priority information that may be required by all subscribers whereas such priority information may consume limited bandwidth only. Hence, in a further embodiment, the at least one multicast channel may comprise data information of at least one of the following types:

- An update data service;

- An electronic programming guide (EPG) .

The update data service can be used to, e.g., update hardware within the premises of the consumer, e.g., a set-top box. For updating purposes, data is transferred to this piece of hard^¬ ware, wherein such data may require limited bandwidth only, but it may also be mandatory for faultless operation of the hardware and hence the whole multicast-service.

Another example of data information that may be conveyed de^¬ spite the actual number of multicast channels actually pro- vided is an electronic programming guide (EPG) . This guide may be necessary at least partly for operating a set-top box appropriately. Furthermore, the data transmitted for this EPG requires limited bandwidth only.

As yet another embodiment, the number of multicast channels to be sent over the at least one access line is chosen ac^¬ cording to the priority information.

It is another embodiment that the method as described herein is run on one of the following network components of a commu^¬ nications network:

- A set-top box;

- An IGMP-host;

- A digital subscriber line access multiplexer (DSLAM) ; - A broadband remote access server (BRAS) ;

- A bandwidth resource controller (BRC) ;

- An Ethernet switch node;

- A router.

It is a further embodiment that the network component is lo^¬ cated near the subscriber of the multicast service. The problem stated supra is also solved by a device for lim^¬ iting a number of multicast channels over at least one access line comprising a processor unit that is arranged such that the method according to the approach provided herewith is run on the processor.

Such processor unit may comprise an FPGA and/or an EPLD and/or an ASIC.

In an embodiment, the device is a communication device, in particular a network component.

In yet a further embodiment, said network component is at least one of the following: - A set-top box;

- An IGMP-host;

- A digital subscriber line access multiplexer (DSLAM) ;

- A broadband remote access server (BRAS) ;

- A bandwidth resource controller (BRC) ; - An Ethernet switch node;

- A router.

The problem as stated above is also solved by a communication system comprising a device according to the approach provided herewith.

Embodiments of the invention are shown and illustrated in the following figures:

Fig.l shows an example of a multicast network;

Fig.2 shows an overview of an IGMP protocol;

Fig.3 shows an IGMP IP Group to Ethernet MAC address map- ping;

Fig.4 shows a format of IGMP messages within the IP message used to establish a multicast group membership. A bandwidth resource controller (BRC) is used as a central entity controlling an overall bandwidth of the network, pref- erably with regard to an aggregation part and a core part of the (sub-) network .

Another entity of the network, e.g., a IGMP (internet group management protocol) multicast router sends a request to the BRC in order to determine whether additional traffic may be routed on a particular path. The BRC usually just replies by accepting or declining such request. Then, it is up to the requesting entity (here the IGMP multicast router) to act ac^¬ cordingly .

There are several possibilities to limit a maximum number of simultaneously permitted multicast channels:

a) Limitation by a customer premise equipment (CPE) : A CPE may be a set-top box at a subscriber side. The CPE can simultaneously process a limited number of multicast channels only due to its hardware and/or firmware limi^¬ tations. Hence, according to the set-top box' limited capacity, there are restrictions regarding a number of simultaneously processed multicast channels at the CPE.

b) Limitation by the DSLAM and CPE:

There are special cases of ATM DSLAM nodes with ADSL support which require a one to one mapping between ATM Permanent Virtual Circuits PVCs (i.e., Virtual Path

Identifier VPI, Virtual Channel Identifier VCI) and a multicast group channel, because of the limited number of ATM PVCs (i.e., VPI, VCI) supported by the DSLAM and by the CPE, which by setting the maximum number of al- lowed PVCs would also limit the number of simultaneous multicast channels. Some network elements (NE) may limit a number of simul^¬ taneous multicast channels by configuring each port (e.g., DSL port) of the access node accordingly.

c) Limitation by enhanced IGMP server support:

Upon every request to join a new (multicast) group, the IGMP server needs to check whether the customer (e.g., via a MAC address) is able to obtain an additional chan^¬ nel in case the customer already obtained a certain amount of other channels.

In the affirmative, which may be a result of checking the bandwidth resource controller (BRC) first, an addi^¬ tional channel is sent to the customer (subscriber) .

This approach, however, forces the IGMP server to provide an extended functionality, because it has to keep track of the multicast stream requested by the customer. Furthermore, there may be additional delay for zapping since each request needs to be transmitted to the IGMP server .

Also, this approach so far does not consider the cus^¬ tomer's access line usage as well as the access line's condition.

These limitations a) to c) result in hardware/firmware re^¬ strictions at the DSLAM and/or at the CPE side.

One embodiment of this approach is to provide a controller at the access node (e.g., at the DSLAM) to administer a band^¬ width of each access line taking into account at least one information that may in particular be associated with a subscriber. Examples for such information are: total bandwidth available, line quality (e.g., a QoS parameter like BER), multicast channel information such as referential and/or sta^¬ tistical bandwidth and/or priority information. Such approach may follow the idea of how to set an "overall port multicast budget" for each access line thereby providing in particular two different kind of information:

a) A static information, e.g., a port multicast budget:

Such budget reflects line bandwidth, static line condi^¬ tion considerations and/or an amount of multicast traf^¬ fic allowed over this access line.

Further, this budget value may be reduced pursuant to non-multicast traffic (e.g., traffic of data services).

b) Dynamic port budget relating to line condition:

A dynamic port budget considers current or previous bit error rate (BER) or any other quality of service (QoS) of the line which can be inferred from reception of re^¬ ported erroneous or discarded frames sent or received. A high bit error rate may result in a reduced (low) over^¬ all port budget.

c) Priority information

In this approach, a multicast channel has a budget that can correspond to a weighted sum of factors like band^¬ width requirement, priority/accepted refusal index fac- tor, etc. These factors can be provided by an operator and/or obtained from the communications network.

A priority information can be used to transmit informa^¬ tion that may only require limited bandwidth, but is mandatory or at least important for the whole multicast scenario. An example of such a mandatory channel is an electronic programming guide (EPG) , another example is a set-top box control channel for, e.g., conveying update information directed to such set-top box. Therefore, such channels may be assigned by operators with higher priorities . The priority information can also be used for implement^¬ ing preemption policies, i.e., policies related to situations where a new channel cannot be added if not dropping one or more channels that are already delivered but are associated with less priority.

Such preemptive functionality is useful in particular because it considers each channel associated priority information that was previously assigned/accepted by customer/subscriber. The automatic termination by the network node of the delivery of a multicast channel may be also compensated automatically by the set-top box that issues an request for a less quality version of the same channel which may be obtained/known from the EGP channel.

For example, a channel priority of subscriber channels (that are non EPG and/or controller channels) can be set by subscribers themselves, e.g., via internet or via the set-top box.

An overall channel bandwidth requirement can be divided in static and dynamic parts: A static budget may be provided by an operator. A dynamic value can be provided (in case it is supported by the network element or node of the communica^¬ tions network) that may be modified (e.g., increased or de^¬ creased) by a factor according to a statistical average rate of the channel as discussed above.

Preferably, a distributed line bandwidth controller is lo^¬ cated at or near the access node (e.g., DSLAM) . Hence, prior to adding a new channel to the multicast-channels to be watched by a particular subscriber (customer of the multicast service) , it has to be checked whether the overall budget does not surpass an overall budget limit configured at the access port for a particular at least one access line. If this limit is exceeded, no multicast channel will be added. However, if the bit error rate (BER) of a particular access line increases, multicast channels already subscribed for may be cancelled (e.g., multicast channels of low importance or multicast channels of high budget) unless the sum of budgets for the multicast-channels equals or is lower than the actual port budget .

Allowing or denying (additional) multicast channels at one interface (port) may result in the controller managing the traffic that requires the biggest portion thereby assuring a certain level of quality of service (QoS) for the traffic sent to the customer (s) or subscriber (s) over the access line .

In order to allow or deny a multicast channel to be conveyed at an access node for a particular access line a technique is applied that uses characteristics of multicast traffic proto^¬ cols as well as of nodes with switching capability.

Fig.l shows an example of a multicast network. A Set-Top Box and an IGMP Host are connected to an UNI Border DSLAM of a L2 Network. This L2 Network further comprises an L2 Aggregation switch I, an L2 Aggregation switch II and a Broadband Remote Access Server BRAS. An L3 Network is connected to the BRAS comprising a Video Server I, a Video Server II and an IGMP Multicast Router.

An user request a multicast channel from the IGMP Multicast Router by conveying a "join message", the IGMP Multicast Router forwards the multicast stream to the user, i.e., the IGMP Host or the Set-Top Box associated with the user.

A protocol for multicast traffic in access networks is IGMP (Internet Group Multicast Protocol) used in IP/Ethernet net- works. The particular connection to the (end) customer may be provided via DSL or Ethernet interfaces (e.g., 10/100 Mbps or 1/10 Gbps) . In IGMP, different multicast groups (e.g., audio or video or data channels) are typically received from the IGMP Multicast Server and are further sent to the customer' s set-top box on explicit request via IGMP "join messages". A suspension may be conducted either by explicit IGMP "leave messages" initi^¬ ated by the set-top box or by a time out event triggered at the IGMP Multicast Router (or from the UNI Border DSLAM in case it is set up as an IGMP Proxy) .

Fig.2 shows an overview of an IGMP protocol. A Multicast

Router is connected with a L2 Aggregation switch, which is further connected to an UNI Border DSLAM. Hosts are connected to this UNI Border DSLAM, which acts as a snooping bridge and monitors and filters IGMP messages.

The IGMP multicast protocol can be used to distribute or mul^¬ ticast IP traffic using a class D IP address in a predeter^¬ mined range from, e.g., 224.0.0.0 to 239.255.255.255.

When IP traffic is conveyed through the Ethernet, e.g. through the DSLAM and/or Ethernet switches, a particular range of Ethernet MAC addresses is reserved especially for multicast purposes. Furthermore, there can even be a special procedure for mapping multicast IP addresses to Ethernet MAC addresses as seen in Fig.3.

Fig.4 shows a format of IGMP messages used to establish a multicast group membership.

Ethernet switching may be based on a so-called "Forwarding Data Base" (FDB) , which basically comprises a look-up table used for switching purposes. Hence, a given destination virtual-LAN (VLAN) address and/or a destination MAC address can be mapped to zero or more interfaces to which that particular VLAN address and/or destination MAC address has to be for^¬ warded. This table in filled by information received previously at the respective ports. E.g., if a new device is connected to a certain port and sends an Ethernet frame, the FDB will be up^¬ dated with a new entry stating that the source MAC address of that frame is accessible from that port.

Usually, the data of the table is successively updated or en^¬ tered by receiving the source VLAN addresses and/or the source MAC addresses of incoming Ethernet frames (which may also be IGMP requests with the multicast group address of the channel the customer wants to watch) .

In order to block a multicast channels at a specific inter^¬ face, this technique requires controlling/managing the multi- cast MAC addresses assignment at the FDB, i.e., the addition of new entries at the FDB for a specific interface port. If a multicast channel request is denied, its MAC address will not be entered into the FDB; hence, there will be no associated multicast channel traffic conveyed to the customer.

The technique described herein shows in particular a techni^¬ cal solution to implement a distributed bandwidth resource controller (BRC) to limit a maximum number of simultaneous IGMP multicast channels that are allowed to be forwarded through an interface of Ethernet nodes. Furthermore, the ap^¬ proach takes into account various parameters for assuring an acceptable overall QoS level for the egress multicast traffic of that interface.

Particular benefits of this approach are:

a) The approach via the bandwidth resource controller (BRC) considers dynamic key parameters important for assuring an acceptable overall QoS level for multicast traffic. Hence, it can be decided whether or not to accept a mul^¬ ticast group to be sent via a predetermined interface. A current or a previous condition of an access line, e.g., an access line's bit error rate, may be consid^¬ ered. The higher a value of the BER, the lesser a number of simultaneously supported multicast channels.

A statistical bandwidth usage of all multicast channels and/or of each multicast channel dynamically measured at uplink port (s) may be considered.

Further, with a reduced previous bandwidth usage a higher number of multicast channels may be added to ef^¬ ficiently use the available bandwidth.

This approach also considers the configuration of static and/or reference key parameters.

A port budget parameter may reflect a line interface bandwidth, a consideration of a static line condition (e.g., static BER) or a maximum of an allowed number of simultaneous multicast channels at a particular port.

Such port budget can also consider non-multicast traf^¬ fic, i.e. the lower such port budget is set, the more non-multicast traffic may be expected.

Each channel can provide a reference budget in particu^¬ lar with a priority information. The reference budget may be used for ensuring an acceptance of the multicast channel at a given interface, thereby ensuring that the overall port budget will not be exceeded.

The priority information can be used for prioritization whenever there is a need to do a pre-emption of some ex^¬ isting multicast channel because of a higher priority as the one actually requested, or due to degraded line con^¬ ditions . Also, the approach provides a distributed line bandwidth controller at or near a network element instead of being centrally located at or with an external BRC.

With the controlling already being performed at the net^¬ work element (NE) , this approach is less expensive, more scalable, lesser risky and it allows shorter zapping times .

This is contrary to a centralized BRC-approach, which is more difficult to implement since the BRC needs to be informed and to be updated by receiving dynamic parame^¬ ters sent from the network elements. This, however, is far less scalable, could easily lead to inconsistencies and would surely imply longer zapping times.

A distributed control means at the network element side therefore is an easier and less expensive approach to implement a managing functionality taking into account both the static/reference input from operators and the dynamic parameters inferred/measured by the network ele^¬ ments themselves.

Claims

Claims :

1. A method for limiting a number of multicast channels over at least one access line according to at least one information that is in particular associated with a subscriber .

2. The method according to claim 1, wherein the at least one information comprises: - A static information;

- A dynamic information;

- A priority information associated with at least one multicast channel.

3. The method according to claim 2, wherein the static information comprises:

- A referential bandwidth;

- A static condition of the at least one access line;

- An amount of multicast traffic allowed on the at least one access line.

4. The method according to any of claims 2 or 3, wherein the dynamic information comprises a dynamic condition of the at least one access line.

5. The method according to claim 4, wherein the dynamic condition is based on a quality of service (QoS) model.

6. The method according to claim 5, wherein the quality of service model comprises at least one of the following criteria :

- A bit error rate (BER) ;

- receivedErroredPackects / receivedPackets;

- frameCheckSequenceErrors / frameCheckSequenceRe- ceived;

- lossOfSynch;

- unavailable seconds;

- severely errored seconds.

7. The method according to any of the claims 2 to 6, wherein the at least one multicast channel comprises data information of at least one of the following types: - An update data service;

- An electronic programming guide (EPG) .

8. The method according to claim 7, wherein the number of multicast channels sent over the at least one access line is chosen according to the priority information.

9. The method according to any of the previous claims, wherein the method is run on one of the following net^¬ work components of a communications network: - A set-top box;

- An IGMP-host;

- A digital subscriber line access multiplexer (DSLAM) ;

- A broadband remote access server (BRAS) ;

- A bandwidth resource controller (BRC) ; - An Ethernet switch node;

- A router.

10. The method according to claim 9, wherein the network component is located near the subscriber of the multi- cast service.

11. A device for limiting a number of multicast channels over at least one access line comprising a processor unit that is arranged such that the method according of any of the preceding claims is executable on said proc^¬ essor .

12. The device according to claim 11, wherein said device is a communication device, in particular a network compo- nent .

13. The device according to claim 12, wherein the network component is at least one of the following: - A set-top box;

- An IGMP-host;

- A digital subscriber line access multiplexer (DSLAM) ;

- A broadband remote access server (BRAS) ; - A bandwidth resource controller (BRC) ;

- An Ethernet switch node;

- A router.

14. Communication system comprising the device according to any of claims 11 to 13.