Charging mechanism for multicasting
An apparatus for calculating a cost of receiving multicast data from a multicast session. A multicast network includes at least one multicast service, each multicast service including at least one multicast session. The apparatus receives a request to establish a connection to the multicast session, stores a start time for the connection and an end time for the connection and, after termination of the connection, calculates the cost of receiving the multicast data. The apparatus can receive a subsequent request to extend the connection, the subsequent request specifying a new end time for the connection, and store the new end time for the connection. Alternatively, the apparatus can receive a subsequent request to terminate the connection, the subsequent request specifying a new end time that precedes the end time for the connection, and store the new end time for the connection.
This application for letters patent is a continuation application and hereby incorporates by reference the parent application, U.S. patent application Ser. No. 10/077,780, titled “Charging Mechanism For Multicasting”, filed in the United States Patent and Trademark Office on Feb. 20, 2002.
This application for letters patent is related to and incorporates by reference U.S. patent application Ser. No. 10/008,334, titled “A System and Method for Efficient Distribution of Multicastable Services”, and filed in the United States Patent and Trademark Office on Dec. 6, 2001.
FIELD OF THE INVENTIONThe invention disclosed herein is a method, system, and computer program product for calculating a cost of receiving multicast data from a multicast session. In particular, the method, system, and computer program product calculates the cost of receiving multicast data based on either the elapsed time that a user connects to a multicast session, or the volume of data received at a destination during the connection period.
BACKGROUND OF THE INVENTIONA one-to-many or many-to-many Internet Protocol (IP) application involves one or multiple sources sending IP messages to multiple receivers. Exemplary applications include the transmission of corporate messages to employees, communication of stock quotes to brokers, video and audio conferencing for remote meetings and telecommuting, and replicating databases and web site information. The IP multicast protocol efficiently supports one-to-many or many-to-many applications by allowing a source to send a single copy of a message to any recipient who explicitly requests to receive the message. IP multicast is more efficient than a point-to-point unicast protocol that requires the source to send an individual copy of a message to each requester thereby limiting the number of receivers by the bandwidth available to the sender. IP multicast is also more efficient than a broadcast protocol that sends one copy of a message to every node on the network even though many of the nodes may not want the message and the broadcast protocol is limited to a single subnet. Furthermore, the IP multicast protocol is applicable not only to wired networks, but also wireless networks. For example, in wireless network, link level multicasting allows several terminals to receive data sent over a single air interface.
IP Multicast is a receiver-based protocol. A receiver subscribes to a multicast session group by sending a join message to the multicast session group. Since the network infrastructure delivers the traffic to each member of the multicast session group, the sender does not need to maintain a list of receivers. The advantage is that only one copy of a multicast message passes over any link in the network. In addition, IP Multicast only creates a copy of the message when the paths diverge at a router. Thus, IP multicast yields many performance improvements and conserves bandwidth throughout the system.
IP multicast is an extension to the standard IP network-level protocol. RFC 1112, titled “Host Extensions for IP Multicasting” and authored by Steve Deering in 1989, describes IP multicasting as “the transmission of an IP datagram to a ‘host group’, a set of zero or more hosts identified by a single IP destination address. IP multicasting delivers a multicast datagram to every member of the destination host group with the same ‘best-efforts’ reliability as regular unicast IP datagrams. The membership of a host group is dynamic; that is, hosts may join and leave groups at any time. There is no restriction on the location or number of members in a host group. A host may be a member of more than one group at a time.” In addition, at the application level, a single group address may have multiple data streams on different port numbers, on different sockets, in one or more applications. Multiple applications may share a single group address on a host.
Multicast communications to establish host membership in a multicast group (e.g., a join message) utilize a standard, such as the Internet Group Management Protocol (IGMP), that supports multicast communication at the Open System Interconnection (OSI) data link layer (layer 2). W. Fenner, Internet Group Management Protocol, Version 2, Request for Comments (RFC) 2236, November, 1997, describe IGMP.
In a shared transport media network, encryption takes place at the Open Systems Initiative (OSI) link level (level 2) to prevent an unintended user on the same point-to-multipoint link to get the multicast packets. Alternatively, Internet Protocol security (IPsec) and tunneling can achieve the same result. In addition, in a shared transport network, it is difficult for a provider to determine a total charge to associate with a multicast service between a source and a user because the total charge comprises a content charge and a delivery charge. The source determines the fee associated with the content charge based on the copyright of the content, the volume of data, or a digital right management (DRM) solution. In contrast, the resources consumed during the delivery of the content to a user such as a content provider dictate the delivery charge. In a wireless network, for example, the resources consumed may include wireless radio resources. The content provider is the owner of the multicast data source, however the actual data may be obtained from a third party who owns the copyright to the content.
The content charge and the delivery charge also differ because the content charge accrues against the user and the delivery charge can accrue against either the content provider or the user. If the delivery charge accrues against the content provider for sending the content over a physical network, the accrual of the charge can be on a program basis, a data volume basis, or a time basis. Accrual of the delivery charge against the content provider is suitable for delivering content such as an advertisement because the content delivery benefits the content. The disadvantage, however, is that accrual of the delivery charge against the content provider requires a service agreement between the content provider and the network operator. Thus, when the delivery charge accrues against the content provider, it is not possible to charge for delivery of multicast services originating from any content provider on Internet. If the delivery charge accrues against the user for receiving the content over a physical network, it is difficult to track the volume of data that the user receives. Thus, only two types of charging mechanisms are possible, flat rate charging and program or file based charging. Flat rate charging requires the user to periodically pay a fixed price for using the service. Program or file based charging requires the user to pay a fee for each request to receive a program or file. In response to the payment, the user receives an encryption key that will allow access to the program or file. The program or file can include a software application, audio/video file, or graphic image. The encryption scheme can include link level encryption or IPsec.
Sophisticated and cost-effective charging mechanisms, such as time based charging and data volume based charging, have taken the place of flat rate charging and program or file based charging mechanisms. A charging scheme based on connection time will calculate a fee for a service based on the amount of time that a user connects to the service. For example, if a network operator determines that the rate for using a video service is $5.00 per hour, a user connecting to the video service to view a movie for thirty-minutes accrues a fee of $2.50. A charging scheme based on the volume of data will calculate a fee for a service based on the volume of data that a user receives from the service. For example, if a network operator determines that the rate for using a video service is $0.25 per Megabyte of data received, the fee for a user to use the video service to view a movie consisting of 25 Megabytes is $6.25.
Currently, time based charging and data volume based charging mechanisms are not available for IP multicast deployed in a network with shared transport media. Since it is difficult to determine when a user has stopped using a shared transport media service, it is difficult for network to calculate the connection time or data volume received. For example, user may establish a multicast connection through a digital broadcast network, but when the battery in the user's terminal loses a charge, the connection is broken without any indication of disjoining the service. Thus, the charging will continue even though the multicast service is no longer in use. Furthermore, security is a problem because the user has the possibility to disjoin the service, but still receives the data from the shared transport media service. This invention disclosed here is one possible solution to establish a secure billing system for multicast service in a network that is capable for link level multicasting.
Thus, there is a need for a system, method, and computer program product for calculating a cost of receiving multicast data from a multicast session. The system, method, and computer program product will calculate the cost of receiving multicast data based on either the elapsed time that a user connects to a multicast session, or the volume of data received at a destination during the connection period. The system, method, and computer program product disclosed herein establish a secure billing system for multicast services in a network that provides link level multicasting.
SUMMARY OF THE INVENTIONA method, system, and computer program product for calculating a cost of receiving multicast data from a multicast session. A multicast network includes at least one multicast service, each multicast service including at least one multicast session. The method, system, and computer program product receives a request to establish a connection to the multicast session, the request including a start time for the connection and an end time for the connection. The method, system, and computer program product stores the start time for the connection and the end time for the connection and, after termination of the connection, calculates the cost of receiving the multicast data.
The method, system, and computer program product can receive a subsequent request to extend the connection, the subsequent request specifying a new end time for the connection, and store the new end time for the connection. Alternatively, the method, system, and computer program product can receive a subsequent request to terminate the connection, the subsequent request specifying a new end time that precedes the end time for the connection, and store the new end time for the connection.
In one embodiment, the storing of the start time for the connection and the end time for the connection is to a database.
To calculate the cost, the method, system, and computer program product computes a charge for receiving the multicast data, stores the charge, and computes the cost by multiplying the charge by a fee for the multicast service associated with the multicast session. In one embodiment, the storing of the charge is to a database. The method, system, and computer program product can compute an elapsed connection time by subtracting the start time for the connection from the end time for the connection. Alternatively, the method, system, and computer program product can compute a volume of data received over the connection from the start time for the connection to the end time for the connection.
In another embodiment, time is divided into evenly spaced time slots such that the start time for the connection the end time for the connection can only occur at the end of a time slot. Alternatively, the end time for the connection in the request is specified as a discrete number of time slots.
In another embodiment, the system for calculating a cost of receiving multicast data from a multicast session includes a collection device and an interface device. The collection device is a general-purpose computer configured to receive a request to establish a connection to the multicast session, the request including a start time for the connection and an end time for the connection, store the start time for the connection and the end time for the connection, and after termination of the connection, calculate the cost of receiving the multicast data. The interface device is a general-purpose computer configured to configure the collection device and display the cost of receiving the multicast data.
BRIEF DESCRIPTION OF THE DRAWINGSThe accompanying figures best illustrate the details of the system, method, and computer program product that establishes a secure billing system for multicast services in a network that provides link level multicasting, both as to its structure and operation. Like reference numbers and designations in the accompanying figures refer to like elements.
As shown in
In another embodiment of the secure billing system shown in
In another embodiment of the secure billing system shown in
In another embodiment of the secure billing system shown in
In another embodiment of the secure billing system shown in
Referring again to
Referring again to
As shown in
An example of the embodiment shown in
At step 228,
At step 234,
At step 228,
At step 234,
Connection Time Charging
A charging scheme based on connection time calculates a fee for a service from the elapsed time that a user connects to the service. For example, if a network operator determines that the rate for using a video service is $5.00 per hour, a user connecting to the video service to view a movie for thirty-minutes accrues a fee of $2.50. In a multicast network, a charging scheme based on connection time is most beneficial when an average multicast session has a fixed bandwidth. Determination of the connection time involves storing the time that the user terminates the multicast session connection, storing the time that the user initiates the multicast session connection, and calculating the difference between these times. Since a multicast session is dynamic, the challenge is to determine when the initiation and termination of the connection occurs.
The packets that comprise a multicast session are encrypted. Thus, a user cannot receive the multicast session without explicitly requesting to join a multicast group and receiving a decryption key. Referring to
The join request sent by the user identifies the requested multicast session, the requested start time for the charging, and the requested stop time for the charging. The join request obligates the user to pay the charges that accrue from the start time to the end time. When the user has “joined” status, the multicast network is responsible for updating the user's “decryption key” whenever host membership in the multicast group changes. For a discussion of several methods for delivery of the decryption key see “Secure Group Communication using Key Graphs”, IEEE/ACM Transactions on Networking, February 2000.
The stop time specified in the join request is the initial stop time for the user's multicast session. The user can extend the stop time by sending a second join request to specify a later stop time. The stop time can only be extended if group membership management 122 receives the second join request prior to the initial stop time. If the second join request arrives after the first join status expires, the user will be disconnecting with the multicast session first as a result of the expired join status. When the second join request arrives, it will act as a new join request to connect user terminal 110 to the multicast session. Following the receipt of a second or subsequent join request, multicast charging unit 124 updates the entry for the user and multicast session in charging database 126 and notifies other group members of a membership change.
In one embodiment, the interval between the start time and the stop time in each join request can be determined based on the configuration set by either the user or network operator. In another embodiment, the interval between the start time and the stop time can be calculated according to an environmental characteristic including the velocity of the terminal, the strength of the reception signal, and the quality of the reception signal.
Termination of the multicast session can happen either explicitly or implicitly. Explicit termination of the multicast session occurs when the user sends a disjoin request that specifies a stop time earlier than the pending stop time. A disjoin request is only effective, however, if group membership management 122 receives the disjoin request prior to the pending stop time. Following receipt of a disjoin request, multicast charging unit 124 updates and closes the entry in charging database 126 and forwards the charging data to billing unit 171 for conversion into billing data and storage in billing database 172. If the forwarding of the charging data is successful, multicast charging unit 124 deletes the entry in charging database 126 and, if the second join request arrives after the first join status expires, multicast security unit 123 updates decryption key 118 for other group members of the same multicast session. Implicit termination of the multicast session occurs when the user's “joined” status expires before the user sends a subsequent join request to extend the stop time. An implicit termination may occur, for example, when the battery in the user's terminal loses power or some other reason that causes terminal to loose the network connection. Accounting for implicit termination of a multicast session ensures that an excessive charge does not accrue for the user.
When the user status changes state from “joined” to “disjoined”, multicast charging unit 124 calculates the total connection time. The billing related information such as user identification data, session identification data, and connection time is transferred from multicast charging unit 124 to billing server 170. Then, billing unit 171 converts the charging data into billing data and stores the billing data in billing database 172. Alternatively, multicast charging unit 124 periodically transfers billing data to billing server 170.
Unrestricted Connection Time
- 1. User terminal 110 sending a join request to group membership management 122 at time tX0. If the join request takes the form join(p, tS1, tE1), the user is requesting to join multicast session p, start the connection time charging at time tS1, and end the connection time charging at time tE1. If the user wants to start the connection time charging immediately, tS1 is set equal to null.
- 2. Multicast security client 113 receiving decryption key 118 from multicast security unit 123 before time tS1. Decryption key 118 functions to decrypt the packet data comprising multicast session p.
3. At time tS1, multicast charging unit 124 adds an entry to charging database 126 to track connection time charges for user terminal 110 using multicast session p. In one embodiment, the entry to charging database 126 appears as follows:
If the user sets tS1 in the join request equal to null to indicate that the connection time charging will start immediately, tX0 will replace tS1 in the charging table because the join request was sent at time tX0.
- 4. From time tS1 until time tE1, the multicast network is responsible for updating decryption key 118 for user terminal 110 whenever host membership in the multicast group changes.
- 5. At time tX1, where tX1<tE1, user terminal 110 extends the stop time by sending a second join request to specify a later stop time. If the second join request takes the form join(p, tE1, tE2), the user is requesting to extend the end time for the connection to multicast session p from time tE1 to time tE2,
6. At time tE1, multicast charging unit 124 updates the entry in charging database 126 to track connection time charges for user terminal 110 using multicast session p. In one embodiment, the entry to charging database 126 appears as follows:
- 7. From time tE1 until time tE2, the multicast network is responsible for updating the “decryption key” for user terminal 110 whenever host membership in the multicast group changes.
8. At time tX2, where tX2<tE2, user terminal 110 sends a disjoin request that specifies a stop time earlier than the pending stop time, tE2. If the disjoin request takes the form leave(p, tE3), user terminal 110 is requesting to leave multicast session p at time tE3. If user terminal 110 wants to leave multicast session p immediately, tE3 is set equal to null. Multicast charging unit 124 updates the entry in charging database 126 to track connection time charges for user terminal 110 using multicast session p. In one embodiment, the entry to charging database 126 appears as follows:
If the user sets tE3 in the disjoin request equal to null to indicate that user terminal 110 wants to leave multicast session p immediately, tX2 will replace tE3 in the charging table because the join request was sent at time tX2.
- 9. At time tE3, collection of connection time charges for user terminal 110 stops. The multicast network is responsible for updating the “decryption key” for the other group members because user terminal 110 disjoined the multicast group. Since the collection of connection time charges has stopped, multicast charging unit 124 closes the entry in charging database 126 for user terminal 110 using multicast session p, communicates the charging data to billing unit 171 for storage in billing database 172, and deletes the entry in charging database 126.
Referring to
- 1. User terminal 110 sending a join request to group membership management 122 at time tX0. If the join request takes the form join(p, tS1, tE1), the user is requesting to join multicast session p, start the connection time charging at time tS1, and end the connection time charging at time tE1. If the user wants to start the connection time charging immediately, tS1 is set equal to null.
- 2. Multicast security client 113 receiving decryption key 118 from multicast security unit 123 before time tS1. Decryption key 118 functions to decrypt the packet data comprising multicast session p.
3. At time tS1, multicast charging unit 124 adds an entry to charging database 126 to track connection time charges for user terminal 110 using multicast session p. In one embodiment, the entry to charging database 126 appears as follows:
If the user sets tS1 in the join request equal to null to indicate that the connection time charging will start immediately, tX0 will replace tS1 in the charging table because the join request was sent at time tX0.
- 4. From time tS1 until time tE1, the multicast network is responsible for updating decryption key 118 for user terminal 110 whenever host membership in the multicast group changes.
- 5. At time tX1, where tX1<tE1, user terminal 110 extends the stop time by sending a second join request to specify a later stop time. If the second join request takes the form join(p, tE1, tE2), the user is requesting to extend the end time for the connection to multicast session p from time tE1 to time tE2.
6. At time tE1, multicast charging unit 124 updates the entry in charging database 126 to track connection time charges for user terminal 110 using multicast session p. In one embodiment, the entry to charging database 126 appears as follows:
- 7. From time tE1 until time tE2, the multicast network is responsible for updating the “decryption key” for user terminal 110 whenever host membership in the multicast group changes.
8. At time tE2, the connection time charging for user terminal 110 expires. Multicast charging unit 124 stops updating the entry for user terminal 110 using multicast session p in charging database 126. Multicast charging unit 124 communicates with billing server 170 to transfer the charging data for user terminal 110 using multicast session p from charging database 126 to billing database 172. Billing unit 171 converts the connection time, data volume, or other form of information for user terminal 110 using multicast session p to the entry of billing database 172, which has information of total cost of multicast session for user terminal 110. Alternatively, the entry in charging database 126 is transferred periodically to billing server 170. In one embodiment, the entry to charging database 126 appears as follows:
Handover
The following examples describe how the system performs charging when a handover occurs from node A to node B. In the first example, the system configuration is as shown in
In the second example, the system configuration is as shown in
For example, before handover, user terminal 110 receives multicast data via node
A. The charging entry is:
Then user terminal 110 begins to perform the handover. At time tH1, where tX2<tE3, node B with group membership management component receives the join request join(p, null, tE4) from user terminal 110. Node B informs multicast charging unit 124 to create a charging entry for user terminal 110. In response, multicast charging unit 124 modifies the existing charging entry in the following manner.
Also, multicast charging unit 124 will inform node A that node A is no longer responsible for the charging entry associated with user terminal 110. Node A may perform disjoin procedures to disjoin user terminal 110 from node A.
Slotted Connection Time
- 1. User terminal 110 sending a join request to group membership management 122 at time tX0. If the join request takes the form join(p, tS1, 2) requesting to join multicast session p, start the connection time charging at time tS1, for the service from the start time until time t3=[(t0+m−tS1)+(2×m)] where m is the duration of a time slot and t0 is the start of a time slot.
- 2. Multicast security client 113 receiving decryption key 118 from multicast security unit 123 before time tS1. The multicast network informs user terminal 110 that time tD1 is the deadline for extending the expiration of the connection to multicast session p. The offset w is defined by the network and represents the time interval between the deadline for receiving another join request and the end of a time slot.
3. At time tS1, multicast charging unit 124 adds an entry to charging database 126 to track connection time charges for user terminal 110 using multicast session p. In one embodiment, the entry to charging database 126 appears as follows:
- 4. From time tS1 until time t3, the multicast network is responsible for updating decryption key 118 for user terminal 110 whenever host membership in the multicast group changes. The updates to decryption key 118 occur during the offset interval w for each time slot. During the offset interval w, if the network determines that the status for a user will change from “joined” to “disjoined”, the network updates decryption key 118.
5. At time tX1, where tX1<tD1, user terminal 110 extends the stop time by sending a second join request to specify a later stop time. If the second join request takes the form join(p, t3, 2), the user is requesting to extend the end time for the connection to multicast session p for 2 time slots after time t3. In one embodiment, the entry to charging database 126 appears as follows:
The multicast network informs user terminal 110 that time tD2 is the deadline for extending the expiration of the connection to multicast session p.
- 6. From time t3 to time t5, the multicast network is responsible for updating decryption key 118 for user terminal 110 whenever host membership in the multicast group changes.
7. At time tX2, where tX2<tD2, user terminal 110 sends a disjoin request that specifies to stop accruing a fee when the current time slot expires. If the disjoin request takes the form leave(p, 0), user terminal 110 is requesting to leave session p when the current time slot expires. In one embodiment, the entry to charging database 126 appears as follows:
- 8. After time (t4−w), if the network determines that the status for a user will change from “joined” to “disjoined”, the network updates decryption key 118 and continues the multicast session for the user into the next time slot.
- 9. At time t4, collection of connection time charges for user terminal 110 stops. The multicast network is responsible for updating the “decryption key” for the other group members because user terminal 110 disjoined the multicast group. Since the collection of connection time charges has stopped, multicast charging unit 124 closes the entry in charging database 126 for user terminal 110 using multicast session p, communicates the charging data to billing unit 171 for storage in billing database 172, and deletes the entry in charging database 126.
Referring to
- 1. User terminal 110 sending a join request to group membership management 122 at time tX0. If the join request takes the form join(p, tS1, 2), the user is requesting to join multicast session p, start the connection time charging at time tS1, and pay for the service from the start time until time t3=[(t0+m−tS1)+(2×m)] where m is the duration of a time slot and t0 is the start of a time slot.
- 2. Multicast security client 113 receiving decryption key 118 from multicast security unit 123 before time tS1. The multicast network informs user terminal 110 that time tD1 is the deadline for extending the expiration of the connection to multicast session p. The offset w is defined by the network and represents the time interval between the deadline for receiving another join request and the end of a time slot.
3. At time tS1, multicast charging unit 124 adds an entry to charging database 126 to track connection time charges for user terminal 110 using multicast session p. In one embodiment, the entry to charging database 126 appears as follows:
- 4. From time tS1 until time t3, the multicast network is responsible for updating decryption key 118 for user terminal 110 whenever host membership in the multicast group changes. The updates to decryption key 118 occur during the offset interval w for each time slot. During the offset interval w, if the network determines that the status for a user will change from “joined” to “disjoined”, the network updates decryption key 118.
5. At time tX1, where tX1<tD1, user terminal 110 extends the stop time by sending a second join request to specify a later stop time. If the second join request takes the form join(p, t3, 2), the user is requesting to extend the end time for the connection to multicast session p for 2 time slots after time t3. In one embodiment, the entry to charging database 126 appears as follows:
The multicast network informs user terminal 110 that time tD2 is the deadline for extending the expiration of the connection to multicast session p.
- 6. From time t3 to time t5, the multicast network is responsible for updating decryption key 118 for user terminal 110 whenever host membership in the multicast group changes.
- 7. After time tD2, if the network determines that the status for a user will change from “joined” to “disjoined”, the network updates decryption key 118 and continues the multicast session for the user into the next time slot.
8. At time t5, collection of connection time charges for user terminal 110 stops. The multicast network is responsible for updating the “decryption key” for the other group members because user terminal 110 disjoined the multicast group. Since the collection of connection time charges has stopped, multicast charging unit 124 closes the entry in charging database 126 for user terminal 110 using multicast session p, communicates the charging data to billing unit 171 for storage in billing database 172, and deletes the entry in charging database 126. Alternatively, multicast charging unit 124 transfers the entry directly to billing server 170. In another embodiment, the entry to charging database 126 appears as follows:
Data Volume Based Charging
A charging scheme based on the volume of data calculates a fee for a service from the volume of data that a user receives from the service. For example, if a network operator determines that the rate for using a video service is $0.25 for each Megabyte of data received, a user connecting to the video service to view a movie consisting of 25 Megabytes of data accrues a fee of $6.25. In a multicast network, a charging scheme based on the volume of data is most beneficial when the data rate varies. Similar to the charging scheme based on connection time discussed above, the connectivity and security is managed on time basis, however, determination of charge requires accounting for the number of bytes transferred during the connection time.
- 1. Data volume meter 125 examining IP multicast data packets and maintaining a tally of the number of bytes of data received, for a given destination address and multicast session. Data volume meter 125 can either be co-located with multicast charging unit 124 or located on an upper layer of the multicast tree (e.g., on the gateway router where the multicast data enters the multicast network). In one embodiment, each last hop router may include a meter for measuring the multicast session routed to the last hop router. In another embodiment, the meter can be distributed across several access routers in the multicast network.
- 2. User terminal 110 sending a join request to group membership management 122 at time tX0. If the join request takes the form join(p, tS1, 2), the user is requesting to join multicast session p, start the connection time charging at time tS1, and pay for the service from the start time until time t3=[(t0+m−tS1)+(2×m)] where m is the duration of a time slot and to is the start of a time slot. Calculation of the fee depends on the volume of data received by a given destination and multicast session between time tS1 and t3.
- 3. Multicast security client 113 receiving decryption key 118 from multicast security unit 123 before time tS1. The multicast network informs user terminal 110 that time tD1 is the deadline for sending another join request. The offset w is defined by the network and represents the time interval between the deadline for receiving another join request and the end of a time slot.
4. At time tS1, data volume meter 125 signals multicast charging unit 124 to add an entry to charging database 126 to store the data volume start value, V1, for user terminal 110 using multicast session p. In one embodiment, the entry to charging database 126 appears as follows:
- 5. From time tS1 until time t3, the multicast network is responsible for updating decryption key 118 for user terminal 110 whenever host membership in the multicast group changes. The updates to decryption key 118 occur during the offset interval w for each time slot. During the offset interval w, if the network determines that the status for a user will change from “joined” to “disjoined”, the network updates decryption key 118.
6. At time tX1, where tX1<tD1, user terminal 110 extends the stop time by sending a second join request to specify a later stop time. If the second join request takes the form join(p, t3, 2), the user is requesting to extend the end time for the connection to multicast session p for 2 time slots after time t3. In one embodiment, the entry to charging database 126 appears as follows:
The multicast network informs user terminal 110 that time tD2 is the deadline for extending the expiration of the connection to multicast session p.
- 7. From time t3 to time t5, the multicast network is responsible for updating decryption key 118 for user terminal 110 whenever host membership in the multicast group changes.
8. At time X2, where tX2<tD2, user terminal 110 sends a disjoin request that specifies to stop accruing a fee when the current time slot expires. If the disjoin request takes the form leave(p, 0), user terminal 110 is requesting to leave session p when the current time slot expires. In one embodiment, the entry to charging database 126 appears as follows:
- 9. After time (t4−w), if the network determines that the status for a user will change from “joined” to “disjoined”, the network updates decryption key 118 and continues the multicast session for the user into the next time slot.
10. At time t4, collection of the data volume charges for user terminal 110 stops. Data volume meter 125 communicates the data volume end value, V2, for user terminal 110 using multicast session p to multicast charging unit 124. Multicast charging unit 124 updates the entry to charging database 126. In one embodiment, the entry to charging database 126 appears as follows:
Since the collection of data volume charges has stopped, multicast charging unit 124 closes the entry in charging database 126 for user terminal 110 using multicast session p, communicates the charging data to billing unit 171 for storage in billing database 172, and deletes the entry in charging database 126. Since the charging data is summarized, the total volume of data for user terminal 110 using multicast session p is (V2−V1). In another embodiment, data volume meter 125 communicates the charging data to billing server 170 directly, without storing the charging data in charging database 126.
Referring to
- 1. Data volume meter 125 examining IP multicast data packets and maintaining a tally of the number of bytes of data received, for a given destination address and multicast session. Data volume meter 125 can either be co-located with multicast charging unit 124 or located on an upper layer of the multicast tree (e.g., on the gateway router where the multicast data enters the multicast network). In one embodiment, each last hop router may include a meter for measuring the multicast session routed to the last hop router. In another embodiment, the meter can be distributed across several access routers in the multicast network.
- 2. User terminal 110 sending a join request to group membership management 122 at time tX0. If the join request takes the form join(p, tS1, 2), the user is requesting to join multicast session p, start the connection time charging at time tS1, and pay for the service from the start time until time t3=[(t0+m−tS1)+(2×m)] where m is the duration of a time slot and to is the start of a time slot. Calculation of the fee depends on the volume of data received by a given destination and multicast session between time tS1 and t3.
- 3. Multicast security client 113 receiving decryption key 118 from multicast security unit 123 before time tS1. The multicast network informs user terminal 110 that time tD1 is the deadline for sending another join request. The offset w is defined by the network and represents the time interval between the deadline for receiving another join request and the end of a time slot.
4. At time tS1, data volume meter 125 signals multicast charging unit 124 to add an entry to charging database 126 to store the data volume start value, V1, for user terminal 110 using multicast session p. In one embodiment, the entry to charging database 126 appears as follows:
- 5. From time tS1 until time t3, the multicast network is responsible for updating decryption key 118 for user terminal 110 whenever host membership in the multicast group changes. The updates to decryption key 118 occur during the offset interval w for each time slot. During the offset interval w, if the network determines that the status for a user will change from “joined” to “disjoined”, the network updates decryption key 118.
6. At time tX1, where tX1<tD1, user terminal 110 extends the stop time by sending a second join request to specify a later stop time. If the second join request takes the form join(p, t3, 2), the user is requesting to extend the end time for the connection to multicast session p for 2 time slots after time t3. In one embodiment, the entry to charging database 126 appears as follows:
The multicast network informs user terminal 110 that time tD2 is the deadline for extending the expiration of the connection to multicast session p.
- 7. From time t3 to time t5, the multicast network is responsible for updating decryption key 118 for user terminal 110 whenever host membership in the multicast group changes.
- 8. After time tD2, if the network determines that the status for a user will change from “joined” to “disjoined”, the network updates decryption key 118 and continues the multicast session for the user into the next time slot.
9. At time t5, collection of the data volume charges for user terminal 110 stops. Data volume meter 125 communicates the data volume end value, V3, for user terminal 110 using multicast session p to multicast charging unit 124. Multicast charging unit 124 updates the entry to charging database 126. In one embodiment, the entry to charging database 126 appears as follows:
Since the collection of data volume charges has stopped, multicast charging unit 124 closes the entry in charging database 126 for user terminal 110 using multicast session p, communicates the charging data to billing unit 171 for storage in billing database 172, and deletes the entry in charging database 126. Since the charging data is summarized, the total volume of data for user terminal 110 using multicast session p is (V3−V1). In another embodiment, data volume meter 125 communicates the charging data to billing server 170 directly, without storing the charging data in charging database 126.
Although the embodiments disclosed herein describe a fully functioning system, method, and computer program product for calculating a cost of receiving multicast data from a multicast session, the reader should understand that other equivalent embodiments exist. Since numerous modifications and variations will occur to those who review this disclosure, the system, method, and computer program product for calculating a cost of receiving multicast data from a multicast session is not limited to the exact construction and operation illustrated and disclosed herein. Accordingly, this disclosure intends all suitable modifications and equivalents to fall within the scope of the claims.
Claims
1-42. (canceled)
43. A system for calculating a cost of receiving multicast data at a mobile terminal from a service provider via a digital video broadcast network, comprising:
- a first multicast serving node in a first coverage area of a digital video broadcast network, coupled to a service provider, for serving multicast data from the service provider to a mobile terminal when in the first coverage area and accumulating charging data as the terminal receives the multicast data;
- a first multicast routing function coupled over the digital video broadcast network to the terminal, for providing first multicast data in a multicast session to the terminal in response to a join request by the terminal to join the multicast session;
- a first multicast charging unit coupled to the first multicast routing function, for accumulating information related to a first charge for providing the first data to the terminal; and
- a billing server coupled to the multicast serving node, for receiving information related to the charging data after the terminal no longer receives multicast data and preparing billing information based on said charging data.
44. The system of claim 43, which further comprises:
- a second multicast serving node in a second coverage area of the digital video broadcast network, coupled to the service provider, for serving multicast data from the service provider to the mobile terminal when in the second coverage area and accumulating charging data as the terminal receives the multicast data from the second multicast serving node;
- a second multicast routing function in the second multicast serving node coupled over the multicast data network to the terminal, for providing second data in the multicast session to the terminal in response to a handover operation when the terminal is in the second coverage area;
- a second multicast charging unit coupled to the second multicast routing function, for accumulating information related to a second charge for providing the second data to the terminal; and
- said billing unit coupled to the first and second multicast charging units for receiving information related to said first and second charges and preparing billing information based on said first and second charges.
45. The system of claim 43, wherein said first multicast serving node further comprises:
- a first multicast security unit coupled to the terminal, for sending a first decryption key to the terminal in response to the join request, to enable the terminal to decrypt encrypted data it receives in the multicast session.
46. The system of claim 44, wherein said second multicast serving node further comprises:
- a second multicast security unit coupled to the terminal, for sending a second decryption key to the terminal in response to the handover operation, to enable the terminal to decrypt encrypted data it receives in the multicast session from the second multicast serving node.
47. The system of claim 45, wherein said second multicast serving node further comprises:
- a second multicast security unit coupled to the terminal, for sending a second decryption key to the terminal in response to the handover operation, to enable the terminal to decrypt encrypted data it receives in the multicast session from the second multicast serving node.
48. The system of claim 43, which further comprises:
- a second multicast serving node in a second coverage area of the digital video broadcast network, coupled to the service provider, for serving multicast data from the service provider to the mobile terminal when in the second coverage area and accumulating charging data as the terminal receives the multicast data from the second multicast serving node;
- a second multicast routing function in the second multicast serving node coupled over the multicast data network to the terminal, for providing second data in the multicast session to the terminal in response to a handover operation when the terminal is in the second coverage area;
- said first multicast charging unit coupled to the second multicast routing function, for accumulating information related to a second charge for providing the second data to the terminal; and
- said billing unit coupled to the first multicast charging unit for receiving information related to said first and second charges and preparing billing information based on said first and second charges.
49. The system of claim 43, which further comprises:
- said first multicast serving node receiving said join request from the terminal to establish a connection to the multicast session, the join request establishing a start time for the connection; and
- said first multicast charging unit calculating the cost of receiving the multicast data after termination of the connection with the first multicast serving node.
50. The system of claim 49, which further comprises:
- said first multicast charging unit calculating the cost of receiving the multicast data as an elapsed time of the connection with the first multicast serving node.
51. The system of claim 44, which further comprises:
- said second multicast serving node handover operation establishing a connection to the multicast session, the handover operation establishing a start time for the connection; and
- said second multicast charging unit calculating the cost of receiving the multicast data after termination of the connection with the second multicast serving node.
52. The system of claim 51, which further comprises:
- said second multicast charging unit calculating the cost of receiving the multicast data as an elapsed time of the connection with the second multicast serving node.
53. A method for calculating a cost of receiving multicast data at a mobile terminal from a service provider via a digital video broadcast network, comprising:
- providing first multicast data in a multicast session to a mobile terminal when in a first coverage area of a digital video broadcast network in response to a join request by the terminal to join the multicast session;
- accumulating information related to a first charge for providing the first data to the terminal;
- providing second multicast data in the multicast session to the mobile terminal when in a second coverage area of the digital video broadcast network in response to a handover operation;
- accumulating information related to a second charge for providing the second data to the terminal; and
- preparing billing information based on said first and second charges.
54. The method of claim 53, which further comprises:
- sending a first decryption key to the terminal in response to the join request, to enable the terminal to decrypt the first data; and
- sending a second decryption key to the terminal in response to the handover operation, to enable the terminal to decrypt the second data.
55. The method of claim 53, which further comprises:
- said join request establishing a start time for providing the first multicast data; and
- calculating the cost of receiving the first multicast data after the terminal ceases receiving the first multicast data, as an elapsed time of receiving the first multicast data.
56. The method of claim 55, which further comprises:
- said handover operation establishing a start time for providing the second multicast data; and
- calculating the cost of receiving the second multicast data after the terminal ceases receiving the first multicast data, as an elapsed time of receiving the first multicast data.
57. A computer program product comprising a computer readable medium containing computer program logic recorded thereon for execution by a processor in communication with said computer readable medium for calculating a cost of receiving multicast data at a mobile terminal from a service provider via a digital video broadcast network, the computer program product comprising:
- program code for providing first multicast data in a multicast session to a mobile terminal when in a first coverage area of a digital video broadcast network in response to a join request by the terminal to join the multicast session;
- program code for accumulating information related to a first charge for providing the first data to the terminal;
- program code for providing second multicast data in the multicast session to the mobile terminal when in a second coverage area of the digital video broadcast network in response to a handover operation;
- program code for accumulating information related to a second charge for providing the second data to the terminal; and
- program code for preparing billing information based on said first and second charges.
58. The computer program product of claim 57, which further comprises:
- program code for sending a first decryption key to the terminal in response to the join request, to enable the terminal to decrypt the first data; and
- program code for sending a second decryption key to the terminal in response to the handover operation, to enable the terminal to decrypt the second data.
59. The computer program product of claim 57, which further comprises:
- said join request establishing a start time for providing the first multicast data; and
- program code for calculating the cost of receiving the first multicast data after the terminal ceases receiving the first multicast data, as an elapsed time of receiving the first multicast data.
60. The computer program product of claim 59, which further comprises:
- said handover operation establishing a start time for providing the second multicast data; and
- program code for calculating the cost of receiving the second multicast data after the terminal ceases receiving the first multicast data, as an elapsed time of receiving the first multicast data.
Type: Application
Filed: Aug 23, 2005
Publication Date: Dec 22, 2005
Inventors: Lin Xu (Lempalaa), Jarno Leinonen (Tampere)
Application Number: 11/208,759