Title of Invention	A METHOD FOR ACCESS CONTROL IN A MULTICAST SYSTEM AND AN ARRANGEMENT THEREOF
Abstract	The present invention relates to methods and arrangements for access control in a multicast system when data is distributed from a source VS on a common link L3 to at least two users U1-U12 via a node BN21 that comprises a request arbiter ARB21. The arbiter is arranged to distribute the data from source to the users. The method comprises the following steps: - A weight is assigned to each user U1-U12 associated with the node BN21. The weights determine each user's allowed bandwidth i.e. bandwidth allowed to use out of available bandwidth on the common link L3. - A request to join a multicast session S81 is received to the node BN21 from a user U1. - Actual bandwidth usage by the user U1 calculated as the sum of the user's bandwidth part of each used session on the common link L3 including the new request, is compared in the node BN21 with the users U1 allowed bandwidth. - The request denied if the available bandwidth is lower than the actual bandwidth.

Title of Invention

A METHOD FOR ACCESS CONTROL IN A MULTICAST SYSTEM AND AN ARRANGEMENT THEREOF

Abstract

The present invention relates to methods and arrangements for access control in a multicast system when data is distributed from a source VS on a common link L3 to at least two users U1-U12 via a node BN21 that comprises a request arbiter ARB21. The arbiter is arranged to distribute the data from source to the users. The method comprises the following steps: - A weight is assigned to each user U1-U12 associated with the node BN21. The weights determine each user's allowed bandwidth i.e. bandwidth allowed to use out of available bandwidth on the common link L3. - A request to join a multicast session S81 is received to the node BN21 from a user U1. - Actual bandwidth usage by the user U1 calculated as the sum of the user's bandwidth part of each used session on the common link L3 including the new request, is compared in the node BN21 with the users U1 allowed bandwidth. - The request denied if the available bandwidth is lower than the actual bandwidth.

Full Text	1 FORM 2 THE PATENTS ACT, 1970 (39 of 1970) & THE PATENTS RULES, 2003 COMPLETE SPECIFICATION (Se section 10, rule 13) "ACCESS CONTROL FOR MULTICAST CHANNEL REQUEST" TELEFONAKTIEBOLAGET LM ERICSSON (publ), of S-164 83 Stockholm, Sweden The following specification particularly describes and ascertains the invention and the manner in which it is to be performed. WO 2005/071903 2 PCT/SE2004/0W073 ACCESS CONTROL FOR MULTICAST CHANNEL RBQOBST TECHNICAL FIELD OF THE INVENTION The present invention relates to methods and arrangements 5 for access control in a multicast system when data is distributed from a source to at least two users. DESCRIPTION OF RELATED ART It is possible to send video over packet networks such as 10 IP- and Ethernet networks. Since the packet stream needed to produce the moving pictures on the TV screen has considerable bandwidth, many networks do not have sufficient total bandwidth to provide for unique video data streams to each user. For TV programs viewed by several users 15 (recipients), it is sufficient to send one packet stream from the source, and duplicate this stream only at points in the network where there is more than one output port, which leads to a viewer. According to this scheme, any link between a recipient and the source carries exactly one copy 20 of the packet stream. A link that is not between the source and a recipient does not carry the packet stream. This technique is called multicast. Multicast is a valuable way of saving bandwidth when data is to be sent to several recipients at the same time. 25 In some multicast systems, control of which links the packet stream is copied to rests with the recipients. Data streams are addressed to rather abstract destination addresses. These addresses do not represent static sets of destinations. They are identification tags, which the users 30 and the network use when negotiating about where streams are to be copied. These addresses are called multicast addresses. According to some protocols for negotiating about WO 2005/071903 PCT/SE2004/000073 3 multicast streams, sources send packets addressed with multicast addresses into the network. Other nodes become recipients of the multicast stream by requesting to be so. IGMP is a protocol for hosts on IP networks to negotiate 5 with Ethernet switches over which multicast streams they are to receive. In some networks there are regions, which do not have sufficient resources to transfer all multicast streams, which nodes might request. This is reasonable since multicast is about handling large data streams. Or, put 10 another way, if there was sufficient bandwidth for all data streams everywhere, there would not be a need for multicast. The hope of the builders of such networks is that requests will be sufficiently congruent (nodes near each other request the same multicast streams to some extent) for the 15 users to be sufficiently satisfied. The resources that may be limited include total bandwidth and total number of streams. For the case when the network is not able to fulfill all requests for multicast streams there is need for an arbiter 20 or resource disperser. A packet transmission apparatus is disclosed in the patent US 2003/0043840. A packet arbiter selects packets by a prescribed algorithm and requests transmission of the packet. The US patent describes a rather static system where current need are not taken into 25 consideration and where fairness is set aside. Since the load on a network is dependent on congruence of requests, the techniques used for resource allocation in the unicast case cannot be applied directly. In the unicast case, the load on the network can be calculated by adding the loads 30 caused by individual users. In the multicast case, requesting a new stream adds the new stream to the load, while requesting a stream already being streamed to another user connected to the same network node adds little or nothing to the load on this node. Therefore the methods for 35 limiting resource utilisation for unicast users cannot be 4 WO 2005/071903 PCT/SE2004/000073 applied to multicast users with reasonable efficiency-Bandwidth limits sufficiently low to ensure that the system is not overloaded would result in severe underutilization of: the network resources. 5 SUVMKBX OF THE INVENTION The present invention solves problems related to resource conflicts in a multicast system. The problems are solved by the invention by limiting accessibility of bandwidth to 10 users before resource conflicts occur. More in detail the problems are solved by the invention by a method for access control in the multicast system when data, is distributed from a source to users on a common link via a. node. The node comprises a request arbiter arranged to 15 select data from the source to the users. The method comprises the following steps: - Assigning a weight to each user associated with, the node, which weights determine each user's allowed bandwidth i.e. bandwidth allowed to use 20 out of available bandwidth on the common link. - Receiving a request to join a multicast session, from a user to the node. - Comparing in the node, actual bandwidth usage by the user calculated as the sum of the user's 25 bandwidth part of each used session on the common link including the new request, with the users allowed bandwidth. An advantage of the invention is that denial of access 30 affects heavy users as a limitation of how much multicast WO 2005/071903 PCT/SE2004/000073 information they get access to rather than affecting users who are trying to go from no information to some information. This means a higher probability of success for users who are trying to get their first channel at the cost 5 of users getting a lower probability of viewing many channels. Another advantage is that a higher number of channels are made available for those who view channels, which are also viewed by others. Thus, the ability to load the distribution 10 network is evened out. Users get more equal opportunities. Or rather, the operator gets control over the opportunities the viewers get to load the network. The invention will now be described more in detail with the aid of preferred embodiments in connection with the enclosed 15 drawings. HRXKF DESCRIPTION OF TBB DRAWINGS Figure 1 shows a block schematic illustration of a multicast communication system used to transfer data from a video 20 source via a request arbiter to users at a destination. Figure 2 discloses a table in which users subscribing to different sessions are shown. Figure 3 discloses a flowchart illustrating a method to prevent resource conflicts in a multicast system. 25 Figure 4 shows a block schematic illustration of a multicast communication system used to transfer data from a video source via request arbiters to users at a destination. Figure 5 discloses a block schematic illustration of a branch node. 30 WO 2065/971903 PCT/SE2W4/000073 6 DETAILED DESCRIPTION OF EMBODIMENTS In figure 1 a multicast transmission system for video transfer is disclosed in a first embodiment. The transmission system transmits and distributes video 5 sequences from a video source VS to several users U1-U96. The users, that are receivers or local distributors of video 'sequences, are symbolized with boxes in figure 1 but for the sake of clarity of figure 1, only the users Ul, U2, U12, U85 and U96 are shown in the figure. The multicast system 10 comprises a source network part S, an access network part AN, and a destination network part DBST. The access network: AN, is a packet transmission network that can be of the type connection oriented or connectionless. The source is in this example a video source VS and the destination consists of 15 different users U1-D96 located in for example offices ox-homes. In this example ninety-six users divided into groups of twelve are connected to different branch nodes BN21-BN28 in the access network, i.e. twelve users are connected to each branch node. The access network AN comprises Ethernet. 20 switches ESI and ES2 that distribute data between the source VS and the branch nodes BN21-BN28. A first link Ll connects the video source VS to the Ethernet switch ESI, a second link L2 connects the Ethernet switch ESI to the Ethernet switch ES2 and a third link L3 connects the Ethernet switch 25 ES2 to a branch node BN21. 200 video sessions are available from the video server VS. The third link L3, which also is called a common branch node link L3 is a 100Mbit/s link. The branch node BN21 is a MUX-unit that distributes data arriving at the node to the users U1-U12, via 8Mbit/s ADSL- 30 links. The user Ul is a distributor in a home to which a TV and a PC are connected. The branch node BN21 comprises currently granted bandwidth requests, the contracted conditions for all users U1-D12 and available resources. Prom these facts a request arbiter ARB. The arbiter considers all WO 2005/071903 7 PCT/SE2004/000073 the arbiter determines for each request whether it should be granted or not. This will be further explained below. According to the invention, each user is assigned a weight to determine how much multicast bandwidth each user is to be 5 allowed to receive. The weight is assigned when the system is configured. Bandwidth availability is hereby proportional, to weight assigned. The weight assigned is translated into the bandwidth available to the user, i.e. the allowed! bandwidth, by using a conversion factor that decreases with. 10 actual load on the third link L3. A user's actual bandwidth on a link is calculated as the sum of the users share in all the sessions subscribed to. If the user is subscribing to sessions S1S2..Sm, the number of: subscribers to these sessions is n1n2..Jim and the bandwidths 15 are b1,b2, bm respectively. The users actual bandwidth is the sum of 6,/n{ for all those sessions. Figure 2 discloses a table of users U1-U12 in relation to subscribed sessions on the third link 13 out of the two hundred sessions S1-S200. As already said, the third link is 20 a 100 Mbit/s link. In this example a bandwidth of 50 Mbit/s is reserved for the subscribed sessions. In figure 2 it can. be seen that Ul has subscribed to sessions S1.S2S51 and that U6 subscribes to sessions S2,SM. In this example each subscribed session requires 1,5Mbit/s out of the reserved 50 25 Mbit/s bandwidth on the link L3. In figure 2 it can be seen, that seventeen different sessions occupy the third link L3 and consequently 50-17x1.5 = 24,5Mbit/s remains available on the third link. This is the so-called available bandwidth. A method according to the invention will now be explained. 30 The method comprises the following steps: WO 2005/071903 PCT/SE2004/000073 8 - When the system is configured each user is assigned a weight. The weight settles the importance of the user. In this example, the users D2-D6 have been assigned the weight 1", U7-U12 5 are assigned the weight 2", U13-U18 are assignee! the weight 3" and U19-U24 have been assigned the weight M". The user Ul has been assigned the weight m3". The weight 1 means in this example that the user is allowed to use 20% of the third 10 link's L3 remaining bandwidth, 2" means 15%, 3n means 10% and 4" means 5%. - A request to join a session is received to the branch node BN from the user Ul. Ul requests to join the session Sn. The arbiter ARB21 starts to 15 determine Ul's actual bandwidth. As can be seen in figure 2, Ul is already part of the sessions SltS2 and Sn. Ul alone uses the session S, while IH shares S2 with eight other users and Sa with two other users. Session Sn is before Ul's request 20 already shared by two other users U8 and U12. As said, each session requires 1,5Mbit/s bandwidth and Ul's actual bandwidth is hereby calculated as the sum of Ul's bandwidth part of each used session, including the new request, i.e. 25 b1.+b2+b51= M+!£+M=2,167 Mbit/s plus the n1 n2 n51 19 3 bandwidth part of the new requested session S81 , which is = — = 0,5 Mbit/s. Ul's actual bandwidth is hereby 2467+0,5 = 2,667 Mbit/s. The arbiter determines available bandwidth. In 30 figure 2 it can be seen that seventeen sessions WO 2005/071903 ' PCT/SE20O4/M6O73 are reserved on the third link L3. This means that a bandwidth of 50-17x1,5 Mbit/s is available on the third link L3, i.e. 24,5 Mbit/s is available. - The arbiter determines bandwidth available to Ul, 5 i.e. the allowed bandwidth. The allowed bandwidth is calculated as available bandwidth on the link L3 in relation to Ul's weight. The weight determines what relative share of the bandwidth reserved for this kind of sessions the user is 10 entitled to. The bandwidth made available to the user is hereby proportional to the weight assigned to the user. In this example, Ul's weight is 3* i.e. Ul is allowed to use 10% of the available bandwidth. Ul's allowed bandwidth is hereby 15 04x24,5=2,45 Mbit/s. - The arbiter compares Ul's actual bandwidth 2,667Mbit/s with Ul's allowed bandwidth 2,45Mbit/s and finds that allowed bandwidth is lower than actual bandwidth. 20 - The arbiter denies the request from Ul. Different scenarios will now be conceived to highlight the advantages of the invention. For example: - Assuming that available bandwidth on the third link L3 is more than the 24,5 Mbit/s i.e. that 25 less users have subscribed to the sessions. Let's assume that the available bandwidth is 30 Mbit/s. Ul's weight is 3 i.e. Ul is allowed to use 10%. This in turn will lead to a situation where the arbiter compares Ul's actual bandwidth 2,667Mbit/s 30 with Ul's allowed bandwidth 3,0 Mbit/s and finds that allowed bandwidth is higher than actual WO 2005/071903 PCT/SE2064/000073 bandwidth. Consequently the arbiter will allow the request from Ul. Again returning to the original example and assuming that Ul has been weighted as a more 5 important user and instead of weight 3" have got weight 2" i.e. Ul is allowed to use 15%. This will lead to a situation where Ul's allowed bandwidth is 045x24=3,6 Mbit/s. This in turn will lead to a situation where the arbiter compares 10 Ul's actual bandwidth 2,667Mbit/s with Ul's allowed bandwidth 3,6 Mbit/s and finds tha-t allowed bandwidth is higher than actual bandwidth. Consequently the arbiter will allow the reques-t from Ul. 15 - Again returning to the original example an assuming that Ul for the first time requests to join a session. In this case Ul's actual bandwidth. will be —=0,5 Mbit/s instead of the earlier 3 2467+0,5=2,667 Mbit/s. This in turn will lead to a 20 situation where the arbiter compares Ul's actual bandwidth 0,5 Mbit/s with Ul's allowed bandwidth 2,45 Mbit/s and finds that actual bandwidth is lower than allowed bandwidth. Consequently the arbiter will allow the request from Ul. 25 - Again returning to the original example and assuming that Ul is the first subscriber requesting to join the session Sn. In this case Ul's actual bandwidth will be 2467+— = 3,667 Mbit/s. Compare if Ul instead was the tenth user 30 to join the session S8,. In this case Ul's actual WO 2005/071903 M PCT/SE2004/OM073 bandwidth would be 2,167+—=2,317 Mbit/s. When 10 comparing the two scenarios it can be seen that the arbiter will allow the request when Ul is number ten but deny the request if Ul is number- 5 one. Let's assume that the requested session S8, was already used by someone ells. This is actually the case with the requested session Sn in the above first embodiment. In this case the new request will not imply any additional load and 10 the user Ul may be allowed to use the session even if not actually justified. The method according to this variation of the first embodiment will enable this, and comprises the following further steps after the arbiter has compared Ul's actual bandwidth 2,667Mbit/s with Ul's allowed bandwidth. 15 2,45Mbit/s (compare the method in the first embodiment): - The arbiter ARB21 finds out that the requested session Sn already is used by at least one other user U8,U12. This information is stored in a memory in the arbiter ARB21. 20 The arbiter allows the request from Ul. Now again returning to the first embodiment. Let's assume, as yet another variation of the first embodiment that the user wants to return back to session Sn after for example a 25 short TV-commercial break. The user is hereby seen as subscribing to the session also for some time after the actual subscription has ended. For a period of time after the actual subscription has ended, the user is guaranteed to be able to come back". The operator sets a so-called 30 qualification time that defines "short. If the user would not be allowed to return after a short commercial break it WO 2005/071903 PCT/SE2864/I00073 12 would cause dissatisfaction. The method according to this variation of the first embodiment comprises the following further steps after the arbiter has compared Ul's actual bandwidth 2,667Mbit/s with Ul's allowed bandwidth 2,45Mbit/s 5 (see the method in the first embodiment) : - The arbiter AKB21 finds that the user Ul used the session Sn a time ago that is less than the predefined qualification time. This information is stored in a memory in the arbiter ARB21. 10 - The user's weight is temporarily changed from 3" to 2', i.e. the user has become a more important user. - The arbiter allows the request from Ul. - When the user later leaves the session, the user's 15 weight will again be changed back to "3” In order to prevent that quick browsing through sessions accumulate extra subscriptions that cause the arbiter to deny subscriptions, there is a need to filter out very short actual subscriptions. The operator hereby defines a so- 20 called guarantee time that defines the time a user must stay at a session in order to later be allowed to come back to the session. This means a variation of the method above whereby the arbiter also checks the guarantee time after having checked the qualification time. The weight will 25 hereby be changed from 3" to 2" only if the user actually used the session a time ago that is less than the predefined qualification time and if the user at that time used the session during a time period that exceeds the predefined guarantee time. 30 In figure 3 the most essential steps of the method can be seen. The flow chart is to be read together with the earlier- WO 2005/071903 13 PCT/SE2604/000073 shown figures. The method according to the invention comprises the following steps: - When the system is configured each user is assigned a weight. The user Ul has been assigned 5 the weight 3". This step can be seen in the flow- chart by a block 101. - A request to join a session is received to the branch node BN from the user Ul. Ul requests to join the session Sn . This step can be seen in the 10 flow chart by a block 102. - The arbiter ARB21 determines Ul's actual bandwidth. Ul',s actual bandwidth is hereby 2467+0,5=2,67 Mbit/s. This step can be seen in the flow chart by a block 103. 15 - The arbiter determines available bandwidth on the third link 13. A bandwidth of 50-17x1,5 Mbit/s is available, i.e. 24,5 Mbit/s is available. This step can be seen in the flow chart by a block 104. - The arbiter determines Ul's allowed bandwidth. 20 Ul's allowed bandwidth is 0,1x24,5=2,45 Mbit/s. This step can be seen in the flow chart by a block 105. - The arbiter compares Ul's actual bandwidth 2,667Mbit/s with Ul's allowed bandwidth 2,45Mbit/s and finds that allowed bandwidth is lower than 25 actual bandwidth. This step can be seen in the flow chart by a block 106. - The arbiter denies the request from Ul. This step can be seen in the flow chart by a block 107. A second embodiment is disclosed in figure 4. The figure 30 shows the same multicast system as was disclosed earlier in WO 2005/071903 14 FCI7SE2004/909073 figure 1. In this example not only the third link 13 is considered to be a critical link regarding conflicts. There is also a potential risk for conflicts in the second link L2. The second link is a lOOMbit/s link and is called a 5 common Ethernet link L2. Also the Ethernet Switch ES2 comprises in this embodiment a request arbiter ARB2. This second embodiment is a continuation of the first embodiment: but it is assumed that the arbiter ARB21 did not deny the previous request from Ul due to for example that user Ul was 10 weighted 2" in accordance with the earlier discussed scenario. When the system was configured each user-associated with the Ethernet Switch was assigned a weight. Ul was, as mentioned, assigned the weight “2", U2-U12 were assigned the weights as said in the first embodiment while 15 the users U13-U96 all were assigned the weight “1”. The method according to the invention in the second embodiment, comprises the following further steps: - After ARB21 has allowed the request from Ul, Ul's request to join the session Sn is forwarded from 20 the branch node BN21 to the Ethernet Switch ES2. - The arbiter ARB2 in the Ethernet Switch ES2 determines Ul's actual bandwidth on the second. link L2. Ul is already part of the sessions SUS2 and S51. These sessions are shared on the second 25 link also by some of the users U13-U96. Ul's actual bandwidth is hereby in this example assumed to be 1,5 Mbit/s. - The request arbiter ARB2 now determines available bandwidth on the second link L2. In this example 30 it . is assumed that a bandwidth of 3 Mbit/s is available on L2. WO 2005/071903 IS PCT/SE2004/000073 The arbiter determines Ul's allowed bandwidth. Dl's weight is 2 (15%) and Ul's allowed bandwidth is consequently 045x3=0,45 Mbit/s. - The arbiter compares Ul's actual bandwidth 1,5 5 Mbit/s with Ul's allowed bandwidth 0,45 Mbit/s and finds that allowed bandwidth is lower than actual bandwidth. - The arbiter ARB2 denies the request from Ul. - The Ethernet Switch ES2 sends a deny-message to 10 the branch node BN21. - The request arbiter ARB21 in the branch node BN21 also denies the request from Ul and hereby frees capacity on the third link L3. 15 In figure 5, the branch node BN21 is disclosed schematically. The node comprises a MDX-unit MU that distributes data from the third link L3 to the different ADSL links ADSL-1. The node also comprises the request arbiter AKB21 that comprises a central unit CU and two 20 memory spaces MEM1 and MEM2. MEM1 comprises the table disclosed in figure 2. MEM2 comprises information about which users have recently left a requested session. The central unit CU fetches information from the third link, the ADSL links and the memory spaces. CU process the 25 information, calculate bandwidths and times, controls the MUX-unit and distributes selected sessions from the third link L3 to the ADSL links. Different variations are of course possible within the scope of the invention. The arrangement in figure 5 can for 30 example be built up differently as long as the functions according to the invention remain. A users weight can be re- WO 2005/071903 16 PCT/SE2004/000073 assigned at any time. Bandwidth occupied by a session may be fixed or may vary. The invention is in other words not limited to the above described and in the drawings shown embodiments but can be modified within the scope of the 5 enclosed claims. WO 2005/071903 PCT/SE2004/000073 1. Method for access control in a multicast system when distributing data from a source (VS) on a common link 5 (L3) to at least two users (U1-D12) via a node (BN21) , characterized by the following steps: - assigning a weight to each user (U1-U12) associated with the node (BN21), which weights determine each user's allowed bandwidth i.e. 10 bandwidth allowed to use out of available bandwidth on the common link (13) ; - receiving to the node (BN21), a request to join a multicast session (Sn), from a user (Ul); - comparing in the node (BN21), actual bandwidth 15 usage by the user (01) calculated as the sum of the user's bandwidth part of each used session on the common link (13) including the new request, with the users (Ul) allowed bandwidth. 20 2. Method for access control in a multicast system according to claim 1, comprising the following further step: - deny the request if the allowed bandwidth is lower than the actual bandwidth. WO 2005/071903 PCT/SE2004/000073 18 3. Method for access control in a multicast system according to claim 1, comprising the following further-steps: - finding out that the requested session (Sn) is used by at least one other user (U8,U12); - allowing the request from Ul. 4. Method for access control in a multicast system according to claim 1, comprising the following further 10 steps: - perceiving that the user (Ul) used the session (5„) less than a predefined qualification time ago; - changing temporarily the user's weight; 15 - allowing the request if the allowed bandwidth is higher than the actual bandwidth. 5. Method for access control in a multicast system according to claim 4, comprising before changing the 20 user's weight, the following further step: - perceiving that the user used the session (Sn) during a time period that exceeds a predetermined guarantee time. WO 2005/071903 19 PC17SE2t*l/t0M?3 6. Method for access control in a multicast system according to claim 4 or 5, comprising the following further steps: - the user (Ul) leaves the requested session S%x; 5 - changing back the user's weight to it's original value. 7. Arrangement for access control in a multicast system when distributing data from a source (VS) on a common. 10 link (l3) to at least two users (U1-U12) via a node (BN21), which arrangement is characterized by: - means for assigning a weight to each user (U1-U12) associated with the node (BN21), which weights determine each user's allowed bandwidth i.e. 15 bandwidth allowed to use out of available bandwidth on the common link (13) ; means in the node (HN21) for receiving a request to join a multicast session (SK), from a user (Ul) ; 20 - means for comparing in the node (BN21), actual bandwidth usage by the user (Ul) calculated as the sum of the user's bandwidth part of each used session on the common link (L3) including the new request, with the users (Ul) allowed bandwidth. 8. Arrangement for access control in a multicast system according to claim 7, comprising means for denying the request if the allowed bandwidth is lower than the actual bandwidth. WO 2005/071903 20 PCT/SE2004/000073 9. Arrangement for access control in a multicast system according to claim 7, comprising: - means for finding out that the requested session 5 (£«) is used by at least one other user (U"8,U12);. - means for allowing the request from Ul. 10. Arrangement for access control in a multicast system according to claim 7, comprising: 10 - means for perceiving that the user (Ul) used the session (Sn) less than a predefined qualification time ago; - means for changing temporarily the user's weight; - means for allowing the request if the allowed 15 bandwidth is higher than the actual bandwidth. 11. Arrangement for access control in a multicast system according to claim 10, comprising: - means for perceiving that the user used the 20 session (Sn) during a time period that exceeds a predetermined guarantee time. 12. Arrangement for access control in a multicast system 25 according to claim 10 or 11, comprising means for WO 2005/071903 21 PCT/SE2004/000073 changing back the user's weight to it's original value. 13. Arrangement for access control in a multicast system according to any of the claims 7-12 comprising means for calculating the user's (Dl) actual bandwidth. 14. Arrangement for access control in a multicast system according to any of the claims 7-13 comprising means for calculating the user's (Dl) allowed bandwidth. Dated this 21ST day of July, 2006 G. Deepak Sriniws Of K&S Partners Agent for the Applicants. 22 Abstract: The present invention relates to methods and arrangements for access control in a multicast system when data is distributed from a source VS on a common link L3 to at least two users U1-U12 via a node 6N21 that comprises a request arbiter ARB21. The arbiter is arranged to distribute the data from source to the users. The method comprises the following steps: - A weight is assigned to each user U1-U12 associated with the node BN21. The weights determine each user's allowed bandwidth i.e. bandwidth allowed to use out of available bandwidth on the common link L3. - A request to join a multicast session S81 is received to the node BN21 from a user U1. - Actual bandwidth usage by the user U1 calculated as the sum of the user's bandwidth part of each used session on the common link L3 including the new request, is compared in the node BN21 with the users U1 allowed bandwidth. - The request denied if the available bandwidth is lower than the actual bandwidth.

Full Text

1
FORM 2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(Se section 10, rule 13)
"ACCESS CONTROL FOR MULTICAST CHANNEL REQUEST"
TELEFONAKTIEBOLAGET LM ERICSSON (publ), of S-164 83 Stockholm, Sweden
The following specification particularly describes and ascertains the invention and the manner in which it is to be performed.

WO 2005/071903 2 PCT/SE2004/0W073
ACCESS CONTROL FOR MULTICAST CHANNEL RBQOBST
TECHNICAL FIELD OF THE INVENTION
The present invention relates to methods and arrangements
5 for access control in a multicast system when data is distributed from a source to at least two users.
DESCRIPTION OF RELATED ART
It is possible to send video over packet networks such as
10 IP- and Ethernet networks. Since the packet stream needed to produce the moving pictures on the TV screen has considerable bandwidth, many networks do not have sufficient total bandwidth to provide for unique video data streams to each user. For TV programs viewed *by several users
15 (recipients), it is sufficient to send one packet stream from the source, and duplicate this stream only at points in the network where there is more than one output port, which leads to a viewer. According to this scheme, any link between a recipient and the source carries exactly one copy
20 of the packet stream. A link that is not between the source and a recipient does not carry the packet stream. This technique is called multicast. Multicast is a valuable way of saving bandwidth when data is to be sent to several recipients at the same time.
25 In some multicast systems, control of which links the packet stream is copied to rests with the recipients. Data streams are addressed to rather abstract destination addresses. These addresses do not represent static sets of destinations. They are identification tags, which the users
30 and the network use when negotiating about where streams are to be copied. These addresses are called multicast addresses. According to some protocols for negotiating about

WO 2005/071903 PCT/SE2004/000073
3
multicast streams, sources send packets addressed with multicast addresses into the network. Other nodes become recipients of the multicast stream by requesting to be so. IGMP is a protocol for hosts on IP networks to negotiate
5 with Ethernet switches over which multicast streams they are to receive. In some networks there are regions, which do not have sufficient resources to transfer all multicast streams, which nodes might request. This is reasonable since multicast is about handling large data streams. Or, put
10 another way, if there was sufficient bandwidth for all data streams everywhere, there would not be a need for multicast. The hope of the builders of such networks is that requests will be sufficiently congruent (nodes near each other request the same multicast streams to some extent) for the
15 users to be sufficiently satisfied. The resources that may be limited include total bandwidth and total number of streams.
For the case when the network is not able to fulfill all requests for multicast streams there is need for an arbiter
20 or resource disperser. A packet transmission apparatus is disclosed in the patent US 2003/0043840. A packet arbiter selects packets by a prescribed algorithm and requests transmission of the packet. The US patent describes a rather static system where current need are not taken into
25 consideration and where fairness is set aside. Since the load on a network is dependent on congruence of requests, the techniques used for resource allocation in the unicast case cannot be applied directly. In the unicast case, the load on the network can be calculated by adding the loads
30 caused by individual users. In the multicast case, requesting a new stream adds the new stream to the load, while requesting a stream already being streamed to another user connected to the same network node adds little or nothing to the load on this node. Therefore the methods for
35 limiting resource utilisation for unicast users cannot be

4
WO 2005/071903 PCT/SE2004/000073
applied to multicast users with reasonable efficiency-Bandwidth limits sufficiently low to ensure that the system is not overloaded would result in severe underutilization of: the network resources.
5
SUVMKBX OF THE INVENTION
The present invention solves problems related to resource conflicts in a multicast system. The problems are solved by the invention by limiting accessibility of bandwidth to
10 users before resource conflicts occur.
More in detail the problems are solved by the invention by a method for access control in the multicast system when data, is distributed from a source to users on a common link via a. node. The node comprises a request arbiter arranged to 15 select data from the source to the users. The method comprises the following steps:
- Assigning a weight to each user associated with,
the node, which weights determine each user's
allowed bandwidth i.e. bandwidth allowed to use
20 out of available bandwidth on the common link.
- Receiving a request to join a multicast session, from a user to the node.
- Comparing in the node, actual bandwidth usage by the user calculated as the sum of the user's
25 bandwidth part of each used session on the common
link including the new request, with the users allowed bandwidth.
An advantage of the invention is that denial of access 30 affects heavy users as a limitation of how much multicast

WO 2005/071903

PCT/SE2004/000073

information they get access to rather than affecting users who are trying to go from no information to some information. This means a higher probability of success for users who are trying to get their first channel at the cost
5 of users getting a lower probability of viewing many channels.
Another advantage is that a higher number of channels are made available for those who view channels, which are also viewed by others. Thus, the ability to load the distribution
10 network is evened out. Users get more equal opportunities. Or rather, the operator gets control over the opportunities the viewers get to load the network.
The invention will now be described more in detail with the aid of preferred embodiments in connection with the enclosed
15 drawings.
HRXKF DESCRIPTION OF TBB DRAWINGS
Figure 1 shows a block schematic illustration of a multicast communication system used to transfer data from a video
20 source via a request arbiter to users at a destination.
Figure 2 discloses a table in which users subscribing to different sessions are shown.
Figure 3 discloses a flowchart illustrating a method to prevent resource conflicts in a multicast system.
25 Figure 4 shows a block schematic illustration of a multicast communication system used to transfer data from a video source via request arbiters to users at a destination.
Figure 5 discloses a block schematic illustration of a branch node.
30

WO 2065/971903 PCT/SE2W4/000073
6
DETAILED DESCRIPTION OF EMBODIMENTS
In figure 1 a multicast transmission system for video transfer is disclosed in a first embodiment. The transmission system transmits and distributes video
5 sequences from a video source VS to several users U1-U96. The users, that are receivers or local distributors of video 'sequences, are symbolized with boxes in figure 1 but for the sake of clarity of figure 1, only the users Ul, U2, U12, U85 and U96 are shown in the figure. The multicast system
10 comprises a source network part S, an access network part AN, and a destination network part DBST. The access network: AN, is a packet transmission network that can be of the type connection oriented or connectionless. The source is in this example a video source VS and the destination consists of
15 different users U1-D96 located in for example offices ox-homes. In this example ninety-six users divided into groups of twelve are connected to different branch nodes BN21-BN28 in the access network, i.e. twelve users are connected to each branch node. The access network AN comprises Ethernet.
20 switches ESI and ES2 that distribute data between the source VS and the branch nodes BN21-BN28. A first link Ll connects the video source VS to the Ethernet switch ESI, a second link L2 connects the Ethernet switch ESI to the Ethernet switch ES2 and a third link L3 connects the Ethernet switch
25 ES2 to a branch node BN21. 200 video sessions are available from the video server VS. The third link L3, which also is called a common branch node link L3 is a 100Mbit/s link. The branch node BN21 is a MUX-unit that distributes data arriving at the node to the users U1-U12, via 8Mbit/s ADSL-
30 links. The user Ul is a distributor in a home to which a TV and a PC are connected. The branch node BN21 comprises currently granted bandwidth requests, the contracted conditions for all users U1-D12 and available resources. Prom these facts a request arbiter ARB. The arbiter considers all

WO 2005/071903 7 PCT/SE2004/000073
the arbiter determines for each request whether it should be granted or not. This will be further explained below.
According to the invention, each user is assigned a weight to determine how much multicast bandwidth each user is to be
5 allowed to receive. The weight is assigned when the system is configured. Bandwidth availability is hereby proportional, to weight assigned. The weight assigned is translated into the bandwidth available to the user, i.e. the allowed! bandwidth, by using a conversion factor that decreases with.
10 actual load on the third link L3.
A user's actual bandwidth on a link is calculated as the sum of the users share in all the sessions subscribed to. If the user is subscribing to sessions S1S2..Sm, the number of:
subscribers to these sessions is n1n2..Jim and the bandwidths
15 are b1,b2, bm respectively. The users actual bandwidth is the
sum of 6,/n{ for all those sessions.
Figure 2 discloses a table of users U1-U12 in relation to subscribed sessions on the third link 13 out of the two
hundred sessions S1-S200. As already said, the third link is
20
a 100 Mbit/s link. In this example a bandwidth of 50 Mbit/s
is reserved for the subscribed sessions. In figure 2 it can.
be seen that Ul has subscribed to sessions S1.S2S51 and that
U6 subscribes to sessions S2,SM. In this example each subscribed session requires 1,5Mbit/s out of the reserved 50
25 Mbit/s bandwidth on the link L3. In figure 2 it can be seen, that seventeen different sessions occupy the third link L3 and consequently 50-17x1.5 = 24,5Mbit/s remains available on the third link. This is the so-called available bandwidth.
A method according to the invention will now be explained. 30 The method comprises the following steps:

WO 2005/071903 PCT/SE2004/000073
8
- When the system is configured each user is
assigned a weight. The weight settles the
importance of the user. In this example, the users
D2-D6 have been assigned the weight *1", U7-U12
5 are assigned the weight *2", U13-U18 are assignee!
the weight *3" and U19-U24 have been assigned the
weight M". The user Ul has been assigned the
weight m3". The weight *1* means in this example
that the user is allowed to use 20% of the third

10 link's L3 remaining bandwidth, *2" means 15%, *3n
means 10% and *4" means 5%.
- A request to join a session is received to the
branch node BN from the user Ul. Ul requests to
join the session Sn. The arbiter ARB21 starts to
15 determine Ul's actual bandwidth. As can be seen in
figure 2, Ul is already part of the sessions SltS2 and Sn. Ul alone uses the session S, while IH shares S2 with eight other users and Sa with two other users. Session Sn is before Ul's request
20 already shared by two other users U8 and U12. As
said, each session requires 1,5Mbit/s bandwidth and Ul's actual bandwidth is hereby calculated as the sum of Ul's bandwidth part of each used session, including the new request, i.e.
25 b1.+b2+b51= M+!£+M=2,167 Mbit/s plus the
n1 n2 n51 19 3
bandwidth part of the new requested session S81 , which is = — = 0,5 Mbit/s. Ul's actual bandwidth is hereby 2467+0,5 = 2,667 Mbit/s.
The arbiter determines available bandwidth. In
30 figure 2 it can be seen that seventeen sessions

WO 2005/071903 ' PCT/SE20O4/M6O73
are reserved on the third link L3. This means that a bandwidth of 50-17x1,5 Mbit/s is available on the third link L3, i.e. 24,5 Mbit/s is available.
- The arbiter determines bandwidth available to Ul,
5 i.e. the allowed bandwidth. The allowed bandwidth
is calculated as available bandwidth on the link L3 in relation to Ul's weight. The weight determines what relative share of the bandwidth reserved for this kind of sessions the user is
10 entitled to. The bandwidth made available to the
user is hereby proportional to the weight assigned to the user. In this example, Ul's weight is *3* i.e. Ul is allowed to use 10% of the available bandwidth. Ul's allowed bandwidth is hereby
15 04x24,5=2,45 Mbit/s.
- The arbiter compares Ul's actual bandwidth
2,667Mbit/s with Ul's allowed bandwidth 2,45Mbit/s
and finds that allowed bandwidth is lower than
actual bandwidth.
20 - The arbiter denies the request from Ul.
Different scenarios will now be conceived to highlight the advantages of the invention. For example:
- Assuming that available bandwidth on the third
link L3 is more than the 24,5 Mbit/s i.e. that
25 less users have subscribed to the sessions. Let's
assume that the available bandwidth is 30 Mbit/s. Ul's weight is *3* i.e. Ul is allowed to use 10%. This in turn will lead to a situation where the arbiter compares Ul's actual bandwidth 2,667Mbit/s
30 with Ul's allowed bandwidth 3,0 Mbit/s and finds
that allowed bandwidth is higher than actual

WO 2005/071903

PCT/SE2064/000073

bandwidth. Consequently the arbiter will allow the request from Ul.
Again returning to the original example and
assuming that Ul has been weighted as a more
5 important user and instead of weight *3" have got
weight *2" i.e. Ul is allowed to use 15%. This
will lead to a situation where Ul's allowed
bandwidth is 045x24=3,6 Mbit/s. This in turn will
lead to a situation where the arbiter compares

10 Ul's actual bandwidth 2,667Mbit/s with Ul's
allowed bandwidth 3,6 Mbit/s and finds tha-t allowed bandwidth is higher than actual bandwidth. Consequently the arbiter will allow the reques-t from Ul.
15 - Again returning to the original example an assuming that Ul for the first time requests to join a session. In this case Ul's actual bandwidth.
will be —=0,5 Mbit/s instead of the earlier 3
2467+0,5=2,667 Mbit/s. This in turn will lead to a
20 situation where the arbiter compares Ul's actual
bandwidth 0,5 Mbit/s with Ul's allowed bandwidth
2,45 Mbit/s and finds that actual bandwidth is
lower than allowed bandwidth. Consequently the
arbiter will allow the request from Ul.
25 - Again returning to the original example and
assuming that Ul is the first subscriber requesting to join the session Sn. In this case
Ul's actual bandwidth will be 2467+— = 3,667
Mbit/s. Compare if Ul instead was the tenth user
30 to join the session S8,. In this case Ul's actual

WO 2005/071903 M PCT/SE2004/OM073
bandwidth would be 2,167+—=2,317 Mbit/s. When
10
comparing the two scenarios it can be seen that
the arbiter will allow the request when Ul is
number ten but deny the request if Ul is number-
5 one.
Let's assume that the requested session S8, was already used
by someone ells. This is actually the case with the
requested session Sn in the above first embodiment. In this
case the new request will not imply any additional load and
10 the user Ul may be allowed to use the session even if not actually justified. The method according to this variation of the first embodiment will enable this, and comprises the following further steps after the arbiter has compared Ul's actual bandwidth 2,667Mbit/s with Ul's allowed bandwidth.
15 2,45Mbit/s (compare the method in the first embodiment):
- The arbiter ARB21 finds out that the requested session Sn already is used by at least one other user U8,U12. This information is stored in a memory in the arbiter ARB21.
20 The arbiter allows the request from Ul.
Now again returning to the first embodiment. Let's assume, as yet another variation of the first embodiment that the user wants to return back to session Sn after for example a
25 short TV-commercial break. The user is hereby seen as subscribing to the session also for some time after the actual subscription has ended. For a period of time after the actual subscription has ended, the user is guaranteed to be able to *come back". The operator sets a so-called
30 qualification time that defines "short*. If the user would not be allowed to return after a short commercial break it

WO 2005/071903 PCT/SE2864/I00073
12
would cause dissatisfaction. The method according to this variation of the first embodiment comprises the following further steps after the arbiter has compared Ul's actual bandwidth 2,667Mbit/s with Ul's allowed bandwidth 2,45Mbit/s
5 (see the method in the first embodiment) :
- The arbiter AKB21 finds that the user Ul used the
session Sn a time ago that is less than the
predefined qualification time. This information is stored in a memory in the arbiter ARB21.
10 - The user's weight is temporarily changed from *3"
to *2', i.e. the user has become a more important user.
- The arbiter allows the request from Ul.
- When the user later leaves the session, the user's
15 weight will again be changed back to "3”
In order to prevent that quick browsing through sessions accumulate extra subscriptions that cause the arbiter to deny subscriptions, there is a need to filter out very short actual subscriptions. The operator hereby defines a so-
20 called guarantee time that defines the time a user must stay at a session in order to later be allowed to come back to the session. This means a variation of the method above whereby the arbiter also checks the guarantee time after having checked the qualification time. The weight will
25 hereby be changed from *3" to *2" only if the user actually used the session a time ago that is less than the predefined qualification time and if the user at that time used the session during a time period that exceeds the predefined guarantee time.
30 In figure 3 the most essential steps of the method can be seen. The flow chart is to be read together with the earlier-

WO 2005/071903

13

PCT/SE2604/000073

shown figures. The method according to the invention comprises the following steps:
- When the system is configured each user is
assigned a weight. The user Ul has been assigned
5 the weight *3". This step can be seen in the flow-
chart by a block 101.
- A request to join a session is received to the
branch node BN from the user Ul. Ul requests to
join the session Sn . This step can be seen in the
10 flow chart by a block 102.
- The arbiter ARB21 determines Ul's actual
bandwidth. Ul',s actual bandwidth is hereby
2467+0,5=2,67 Mbit/s. This step can be seen in the
flow chart by a block 103.
15 - The arbiter determines available bandwidth on the
third link 13. A bandwidth of 50-17x1,5 Mbit/s is available, i.e. 24,5 Mbit/s is available. This step can be seen in the flow chart by a block 104.
- The arbiter determines Ul's allowed bandwidth.
20 Ul's allowed bandwidth is 0,1x24,5=2,45 Mbit/s. This
step can be seen in the flow chart by a block 105.
- The arbiter compares Ul's actual bandwidth
2,667Mbit/s with Ul's allowed bandwidth 2,45Mbit/s
and finds that allowed bandwidth is lower than
25 actual bandwidth. This step can be seen in the
flow chart by a block 106.
- The arbiter denies the request from Ul. This step
can be seen in the flow chart by a block 107.
A second embodiment is disclosed in figure 4. The figure
30 shows the same multicast system as was disclosed earlier in

WO 2005/071903 14 FCI7SE2004/909073
figure 1. In this example not only the third link 13 is considered to be a critical link regarding conflicts. There is also a potential risk for conflicts in the second link L2. The second link is a lOOMbit/s link and is called a
5 common Ethernet link L2. Also the Ethernet Switch ES2 comprises in this embodiment a request arbiter ARB2. This second embodiment is a continuation of the first embodiment: but it is assumed that the arbiter ARB21 did not deny the previous request from Ul due to for example that user Ul was
10 weighted *2" in accordance with the earlier discussed scenario. When the system was configured each user-associated with the Ethernet Switch was assigned a weight. Ul was, as mentioned, assigned the weight “2", U2-U12 were assigned the weights as said in the first embodiment while
15 the users U13-U96 all were assigned the weight “1”. The method according to the invention in the second embodiment, comprises the following further steps:
- After ARB21 has allowed the request from Ul, Ul's
request to join the session Sn is forwarded from
20 the branch node BN21 to the Ethernet Switch ES2.
- The arbiter ARB2 in the Ethernet Switch ES2
determines Ul's actual bandwidth on the second.
link L2. Ul is already part of the sessions SUS2 and S51. These sessions are shared on the second
25 link also by some of the users U13-U96. Ul's
actual bandwidth is hereby in this example assumed to be 1,5 Mbit/s.
- The request arbiter ARB2 now determines available
bandwidth on the second link L2. In this example
30 it . is assumed that a bandwidth of 3 Mbit/s is
available on L2.

WO 2005/071903

IS

PCT/SE2004/000073

The arbiter determines Ul's allowed bandwidth. Dl's weight is *2* (15%) and Ul's allowed bandwidth is consequently 045x3=0,45 Mbit/s.
- The arbiter compares Ul's actual bandwidth 1,5
5 Mbit/s with Ul's allowed bandwidth 0,45 Mbit/s and
finds that allowed bandwidth is lower than actual bandwidth.
- The arbiter ARB2 denies the request from Ul.
- The Ethernet Switch ES2 sends a deny-message to
10 the branch node BN21.
- The request arbiter ARB21 in the branch node BN21
also denies the request from Ul and hereby frees
capacity on the third link L3.
15 In figure 5, the branch node BN21 is disclosed schematically. The node comprises a MDX-unit MU that distributes data from the third link L3 to the different ADSL links ADSL-1. The node also comprises the request arbiter AKB21 that comprises a central unit CU and two
20 memory spaces MEM1 and MEM2. MEM1 comprises the table disclosed in figure 2. MEM2 comprises information about which users have recently left a requested session. The central unit CU fetches information from the third link, the ADSL links and the memory spaces. CU process the
25 information, calculate bandwidths and times, controls the MUX-unit and distributes selected sessions from the third link L3 to the ADSL links.
Different variations are of course possible within the scope
of the invention. The arrangement in figure 5 can for
30 example be built up differently as long as the functions
according to the invention remain. A users weight can be re-

WO 2005/071903 16 PCT/SE2004/000073
assigned at any time. Bandwidth occupied by a session may be fixed or may vary. The invention is in other words not limited to the above described and in the drawings shown embodiments but can be modified within the scope of the
5 enclosed claims.

WO 2005/071903

PCT/SE2004/000073

1. Method for access control in a multicast system when distributing data from a source (VS) on a common link
5 (L3) to at least two users (U1-D12) via a node (BN21) , characterized by the following steps:
- assigning a weight to each user (U1-U12)
associated with the node (BN21), which weights
determine each user's allowed bandwidth i.e.
10 bandwidth allowed to use out of available
bandwidth on the common link (13) ;
- receiving to the node (BN21), a request to join a
multicast session (Sn), from a user (Ul);
- comparing in the node (BN21), actual bandwidth
15 usage by the user (01) calculated as the sum of
the user's bandwidth part of each used session on the common link (13) including the new request, with the users (Ul) allowed bandwidth.
20 2. Method for access control in a multicast system according to claim 1, comprising the following further step:
- deny the request if the allowed bandwidth is lower than the actual bandwidth.

WO 2005/071903 PCT/SE2004/000073
18
3. Method for access control in a multicast system according to claim 1, comprising the following further-steps:
- finding out that the requested session (Sn) is used by at least one other user (U8,U12);
- allowing the request from Ul.
4. Method for access control in a multicast system according to claim 1, comprising the following further
10 steps:
- perceiving that the user (Ul) used the session
(5„) less than a predefined qualification time ago;
- changing temporarily the user's weight;
15 - allowing the request if the allowed bandwidth is
higher than the actual bandwidth.
5. Method for access control in a multicast system according to claim 4, comprising before changing the
20 user's weight, the following further step:
- perceiving that the user used the session (Sn) during a time period that exceeds a predetermined guarantee time.

WO 2005/071903 19 PC17SE2t*l/t0M?3
6. Method for access control in a multicast system according to claim 4 or 5, comprising the following further steps:
- the user (Ul) leaves the requested session S%x;
5 - changing back the user's weight to it's original
value.
7. Arrangement for access control in a multicast system when distributing data from a source (VS) on a common.
10 link (l3) to at least two users (U1-U12) via a node (BN21), which arrangement is characterized by:
- means for assigning a weight to each user (U1-U12)
associated with the node (BN21), which weights
determine each user's allowed bandwidth i.e.
15 bandwidth allowed to use out of available
bandwidth on the common link (13) ;
means in the node (HN21) for receiving a request
to join a multicast session (SK), from a user
(Ul) ;
20 - means for comparing in the node (BN21), actual bandwidth usage by the user (Ul) calculated as the sum of the user's bandwidth part of each used session on the common link (L3) including the new request, with the users (Ul) allowed bandwidth.
8. Arrangement for access control in a multicast system according to claim 7, comprising means for denying the request if the allowed bandwidth is lower than the actual bandwidth.

WO 2005/071903

20

PCT/SE2004/000073

9. Arrangement for access control in a multicast system
according to claim 7, comprising:
- means for finding out that the requested session
5 (£«) is used by at least one other user (U"8,U12);.
- means for allowing the request from Ul.
10. Arrangement for access control in a multicast system
according to claim 7, comprising:
10 - means for perceiving that the user (Ul) used the
session (Sn) less than a predefined qualification time ago;
- means for changing temporarily the user's weight;
- means for allowing the request if the allowed
15 bandwidth is higher than the actual bandwidth.
11. Arrangement for access control in a multicast system
according to claim 10, comprising:
- means for perceiving that the user used the
20 session (Sn) during a time period that exceeds a
predetermined guarantee time.
12. Arrangement for access control in a multicast system 25 according to claim 10 or 11, comprising means for

WO 2005/071903

21

PCT/SE2004/000073

changing back the user's weight to it's original value.
13. Arrangement for access control in a multicast system according to any of the claims 7-12 comprising means for calculating the user's (Dl) actual bandwidth.
14. Arrangement for access control in a multicast system according to any of the claims 7-13 comprising means for calculating the user's (Dl) allowed bandwidth.
Dated this 21ST day of July, 2006
G. Deepak Sriniws
Of K&S Partners
Agent for the Applicants.

22
Abstract:
The present invention relates to methods and arrangements for access control in a multicast system when data is distributed from a source VS on a common link L3 to at least two users U1-U12 via a node 6N21 that comprises a request arbiter ARB21. The arbiter is arranged to distribute the data from source to the users. The method comprises the following steps: - A weight is assigned to each user U1-U12 associated with the node BN21. The weights determine each user's allowed bandwidth i.e. bandwidth allowed to use out of available bandwidth on the common link L3. - A request to join a multicast session S81 is received to the node BN21 from a user U1. - Actual bandwidth usage by the user U1 calculated as the sum of the user's bandwidth part of each used session on the common link L3 including the new request, is compared in the node BN21 with the users U1 allowed bandwidth. - The request denied if the available bandwidth is lower than the actual bandwidth.

A METHOD FOR ACCESS CONTROL IN A MULTICAST SYSTEM AND AN ARRANGEMENT THEREOF

Documents:

Inventors:

PCT Conventions: