WO2008151528A1 - Procédé, dispositif et système pour commander une ressource de multidiffusion - Google Patents

Procédé, dispositif et système pour commander une ressource de multidiffusion Download PDF

Info

Publication number
WO2008151528A1
WO2008151528A1 PCT/CN2008/070904 CN2008070904W WO2008151528A1 WO 2008151528 A1 WO2008151528 A1 WO 2008151528A1 CN 2008070904 W CN2008070904 W CN 2008070904W WO 2008151528 A1 WO2008151528 A1 WO 2008151528A1
Authority
WO
WIPO (PCT)
Prior art keywords
resource
multicast
bearer
network entity
request
Prior art date
Application number
PCT/CN2008/070904
Other languages
English (en)
French (fr)
Inventor
Shibi Huang
Yu Zuo
Ning Zhu
Original Assignee
Huawei Technologies Co., Ltd.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Huawei Technologies Co., Ltd. filed Critical Huawei Technologies Co., Ltd.
Priority to EP08734259A priority Critical patent/EP2081323A4/en
Priority to JP2010500058A priority patent/JP4787376B2/ja
Publication of WO2008151528A1 publication Critical patent/WO2008151528A1/zh
Priority to US12/428,771 priority patent/US8264998B2/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/781—Centralised allocation of resources
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H04L12/02—Details
    • H04L12/16—Arrangements for providing special services to substations
    • H04L12/18—Arrangements for providing special services to substations for broadcast or conference, e.g. multicast
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/80—Actions related to the user profile or the type of traffic
    • H04L47/806—Broadcast or multicast traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W4/00—Services specially adapted for wireless communication networks; Facilities therefor
    • H04W4/06—Selective distribution of broadcast services, e.g. multimedia broadcast multicast service [MBMS]; Services to user groups; One-way selective calling services
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W72/00—Local resource management

Definitions

  • the present invention relates to the field of communications and networks, and in particular, to a method, device and system for controlling multicast bearer resources. Background technique
  • IPTV Internet Protocol Television
  • LTV/BTV live/broadcast television service
  • the Resource and Admission Control Subsystem (RACS) architecture is described in detail in Internet Converged Services and Protocols for Advanced Networking.
  • the RACS shields the service layer from the specific details of the transport network, supports the separation of service control and transport functions, and senses the resource usage of the transport network downwards to ensure the correct and rational use of transport network resources to ensure the service. Quality of service and prevention of bandwidth and business theft.
  • the functional architecture diagram of the RACS is shown in Figure 1. The main network elements in the figure are as follows:
  • the Service-based Policy Decision Function provides a unified interface to the application layer, shields the underlying network topology and specific access types, and provides service-based policy control.
  • SPDF based on application features (Application The function, the following cartridge: AF) requests the local policy, and maps the request to the Internet Protocol Quality of Sevice (IPQoS) parameter, which is sent to the access side resource and the admission control function (
  • IPQoS Internet Protocol Quality of Sevice
  • the Access-Resource and Admission Control Function the following cartridges are called: A-RACF and the Border Gateway Function (BIG), to request the corresponding resources.
  • the A-RACF is located in the access network and has the function of admission control and network policy aggregation.
  • the A-RACF receives the request from the SPDF and then implements admission control based on the saved policy, accepting or rejecting the request for the transmission resource.
  • A-RACF obtains network attachment information and quality of service (Quality of Service, QoS) list information from the Network Attachment Subsystem (hereinafter referred to as NASS) through the e4 reference point.
  • QoS Quality of Service
  • the location information (e.g., the address of the physical node accessing the user) determines available network resources while referring to the user QoS list information when processing the resource allocation request.
  • the BGF is a border gateway, which can be located between the access network and the core network (implementing the core border gateway function), or between the two core networks (implementing the interconnect border gateway function) .
  • BGF performs Network Address Translation (NAT), gating, QoS marking, bandwidth limitation, usage measurement, and resource synchronization.
  • the Resource Control Enforcement Function (hereinafter referred to as: RCEF) implements the Layer 2/L3 (L2/L3) media stream policy defined by the access operator through the Re reference point, and completes the gating. , QoS marking, bandwidth limitation and other functions.
  • the Layer 2 Termination Function (L2TF) is a functional entity that terminates Layer 2 connections in the access network. RCEF and L2TF are two different functional entities that are usually implemented together on the physical device IP edge (IP EDGE).
  • C-RACF Core-RACF
  • the bearer layer network is divided into three segments: an access network, an access aggregation network, and a core network, as shown in FIG. 2 .
  • the UE User Equipment
  • the UE is referred to as an access network segment between the admission control execution node (possibly AN (Aces Node) or IP EDGE).
  • the node to the core boundary node is called an access aggregation network, and the core boundary node. Also known as the core network.
  • SPDF returns the final result of the resource authorization to AF.
  • the inventor found that the IPTV multicast service has been implemented in the traditional network, but in the RACS, the effective control of the multicast bearer resources has not been implemented. Summary of the invention
  • the embodiment of the invention provides a method, a device and a system for controlling multicast bearer resources, so as to implement control of multicast bearer resources based on RACS.
  • the method of the embodiment of the present invention includes the following steps:
  • the resource and admission control network entity receives a control request of a multicast bearer resource from a bearer layer network entity; and the resource and admission control network entity performs multicast bearer resource control on the request.
  • the network entity of the embodiment of the present invention is located in the RACS, and includes: a receiving unit, configured to receive a control request for a multicast bearer resource from a bearer layer network entity; and a control unit, configured to perform multicast bearer on the request received by the receiving unit Resource control.
  • the control system of the multicast bearer resource in the embodiment of the present invention includes: a bearer layer network entity, configured to send a multicast bearer resource control request; and a network entity in the RACS, configured to receive the multicast bearer resource from the bearer layer network entity The control request, and the multicast bearer resource control of the request.
  • the bearer layer network entity forwards the request to the RACS; the network entity in the RACS receives the control of the multicast bearer resource from the bearer layer network entity.
  • the multicast bearer resource control is performed on the request.
  • the RACS can support the resource control of the multicast service flow, so as to prevent the management and admission control functions of the multicast resources from being introduced to the bearer layer entity, and the centralized management of the multicast and unicast resources can be implemented to ensure unicast and The multicast service fully shares the bearer resources.
  • Figure 1 is a functional architecture diagram of an existing RACS
  • FIG. 2 is a schematic diagram of dividing a bearer layer network into three segments
  • FIG. 3 is a flowchart of steps of a method for controlling a multicast bearer resource according to an embodiment of the present invention
  • FIG. 4 is a schematic structural diagram of a RACS network entity in a multicast bearer resource control apparatus according to an embodiment of the present invention
  • FIG. 5 is a flowchart of a method for controlling a multicast bearer resource according to Embodiment 1 of the present invention
  • FIG. 6 is a flowchart of a method for controlling a multicast bearer resource according to Embodiment 2 of the present invention.
  • FIG. 7 is a flowchart of a method for controlling a multicast bearer resource according to Embodiment 3 of the present invention.
  • FIG. 8 is a flowchart of a method for controlling a multicast bearer resource according to Embodiment 4 of the present invention.
  • FIG. 9 is a flowchart of a method for controlling a multicast bearer resource according to Embodiment 5 of the present invention.
  • FIG. 10 is a flowchart of a method for controlling multicast bearer resources according to Embodiment 6 of the present invention
  • FIG. 11 is a flowchart of a method for controlling multicast bearer resources according to Embodiment 7 of the present invention. detailed description
  • the embodiment of the present invention provides a scheme for controlling the multicast bearer resource by using the RACS, so that the RACS can support the resource control of the multicast service flow, thereby ensuring the IPTV multicast service. successfully launch.
  • the embodiment of the present invention provides a method for controlling a multicast bearer resource.
  • the method includes the following steps:
  • the network entity in the Sl and RACS receives the control request of the multicast bearer resource from the bearer layer network entity.
  • the bearer layer entity (which may be an AN or an IP EDGE) needs to actively send a request message to the multicast group, change the resource request message, or release the resource request message.
  • the RACS initiates a corresponding multicast bearer resource control request, thereby transferring the control of the multicast bearer resource to the RACS for execution.
  • the network entity in S2 and RACS performs multicast bearer resource control on the request.
  • the network entity in the RACS performs multicast bearer resource control and returns a control response to the request sent by the bearer layer network entity.
  • Case 1 The network entity in the RACS receives the network from the bearer layer. The entity requests the multicast bearer resource message; the network entity in the RACS performs multicast bearer resource admission authorization and resource reservation for the request, and returns a resource application result response to the bearer layer network entity.
  • the A-RACF receives the request for the multicast bearer resource from the bearer layer network entity, and then performs the access side group on the request.
  • the bearer resource access authorization and resource reservation are broadcasted, and the resource application result response is returned to the bearer layer network entity according to the application result of the access side.
  • the A-RACF performs the access-side multicast bearer resource access authorization and resource reservation for the request, and applies to the SPDF or C-RACF for the core network.
  • the multicast carries the resource, and returns a resource application result response to the bearer layer network entity according to the application result of the access side and the core network.
  • the SPDF After the SPDF receives the request for the multicast bearer resource from the bearer layer network entity, the SPDF requests the access side multicast bearer resource from the A-RACF, and returns the resource to the bearer layer network entity according to the application result of the access side. The result of the application is responsive.
  • the SPDF applies for the access side and the core network multicast bearer resources to the A-RACF and the C-RACF respectively, and applies according to the access side and the core network. As a result, a resource request result response is returned to the bearer layer network entity.
  • Case 2 The network entity in the RACS receives the message of changing the multicast bearer resource from the bearer layer network entity; the network entity in the RACS performs the access authorization and resource change of the multicast bearer resource change to the request, and sends the resource to the bearer layer. The network entity returns a resource change result response.
  • A-RACF receives the modified multicast bearer resources from the bearer layer network entity.
  • the access authorization and resource change of the access side multicast 7_resource change are performed on the request, and the resource change result response is returned to the bearer layer network entity according to the change result of the access side.
  • the A-RACF receives the request for changing the multicast bearer resource from the bearer layer network entity, and performs the access authorization and resource change of the access side multicast resource change for the request, and also requests the SPDF or the C-RACF.
  • the core network multicast bearer resource is changed, and a resource change result response is returned to the bearer layer network entity according to the change result of the access side and the core network.
  • the SPDF requests the A-RACF to change the access side multicast bearer after receiving the request for changing the multicast bearer resource from the bearer layer network entity.
  • the resource returns a resource change result response to the bearer layer network entity according to the change result of the access side.
  • the SPDF receives the request for changing the multicast 7
  • Case 3 The network entity in the RACS receives the request message for releasing the multicast bearer resource from the bearer layer network entity; the network entity in the RACS releases the corresponding multicast bearer resource, and returns a release result response to the bearer layer network entity.
  • the A-RACF receives the request for releasing the multicast bearer resource from the bearer layer network entity, and then releases the multicast bearer on the access side.
  • the resource returns a release result response to the bearer layer network entity according to the release result of the access side.
  • the A-RACF receives the request for releasing the multicast bearer resource from the bearer layer network entity, releases the multicast bearer resource of the access side, and requests the SPDF or the C-RACF to release the core network multicast bearer resource, and according to the access
  • a release result response is returned to the bearer layer network entity.
  • the SPDF requests the A-RACF to release the access side multicast after receiving the request for releasing the multicast bearer resource from the bearer layer network entity. Carrying resources, and according to the release result of the access side, A release result response is returned to the bearer layer network entity.
  • the SPDF receives the request for releasing the multicast bearer resource from the bearer layer network entity, and then requests the A-RACF and the C-RACF to release the multicast bearer resources of the access side and the core network, respectively, according to the access side and the core network. The result is released, and the release result response is returned to the bearer layer network entity.
  • the embodiment of the present invention further provides a network entity, which is located in the RACS, and specifically may be
  • A-RACF or SPDF as shown in FIG. 4, includes: a receiving unit, a control unit; and further includes: a response unit.
  • a receiving unit configured to receive a control request for a multicast bearer resource from a bearer layer network entity
  • the control unit is configured to perform multicast bearer resource control on the request received by the receiving unit, and the response unit is configured to return a control response to the bearer layer network entity that initiates the request.
  • the embodiment of the invention further provides a multicast bearer network, which includes: a bearer layer network entity and a network entity in the RACS.
  • a bearer layer network entity configured to send a control request for a multicast bearer resource
  • the network entity in the RACS is configured to receive a control request for the multicast bearer resource from the bearer layer network entity, perform multicast bearer resource control on the request, and return a control response to the bearer layer network entity. Specifically, the network entity in the RACS controls the request on the access side multicast bearer resource, or controls the request on the access side and the core network multicast bearer resource.
  • Embodiment 1 When the A-RACF is used as the final policy decision point, the bearer layer network entity IP EDGE or AN receives the multicast group request from the user, and then applies for the multicast resource to the A-RACF. In the case of the side policy and the resource, the access-side multicast bearer resource access authorization and resource reservation are performed. Optionally, the A-RACF may also apply to the SPDF/CR ACF for the core network multicast bearer resource. The A-RACF returns the final response to the bearer layer according to the access side or the integrated network application result.
  • the IP EDGE/AN receives the request of the user to join the multicast group, obtains the multicast group address and the user IP address that the user desires to join, and may also obtain the multicast source address (one or more). And information such as source address filtering mode (such as EXCLUDE or INCLUDE).
  • source address filtering mode such as EXCLUDE or INCLUDE
  • the IP EDGE/AN sends an application request for the multicast bearer resource to the A-RACF, where the request carries the IP address or identifier of the user and the description information of the multicast stream.
  • the description of the multicast stream must include the multicast group D address, optionally including the multicast source address (one or more), and the source address filtering mode (such as EXCLUDE or INCLUDE). If the IP EDGE/AN is configured with the bandwidth resource information required by the multicast group, it needs to be carried in the request.
  • This step involves the related content of resource authorization, including the following two parts: Firstly, A-RACF can authorize the request according to the user's multicast service authority.
  • the A-RACF performs access-side multicast bearer resource admission authorization and resource reservation according to the access side policy and resource status. Specifically, if there is no bandwidth information in the multicast bearer resource request, the BJA-RACF queries the local configuration to obtain the bandwidth required by the multicast group. If the A-RACF determines that the multicast stream already exists on the IP EDGE/AN, the grant and the resource reserve the access network resource; otherwise, the grant and the resource need to reserve the access network resource and the convergence network resource.
  • the A-RACF can also apply to the SPDF/C-RACF for the core network multicast bearer resource, that is, perform 4-6 steps.
  • the A-RACF sends an application for the core network multicast bearer resource to the SPDF/C-RACF, and the information carried in the request is the same as in the second step.
  • SPDF/C-RACF authorizes core network side resources.
  • SPDF/C-RACF returns the authorization result, indicating whether the resource authorization is passed.
  • the A-RACF returns a resource authorization result response to the IP EDGE/AN according to the application result of the access side, or the access side and the core side.
  • Embodiment 2 When A-RACF is used as the final policy decision point, when the carrier layer network entity IP
  • the EDGE/AN receives a request from the user to change the multicast source address or other signaling that triggers resource changes.
  • the A-RACF initiates a change request for the multicast bearer resource, and the A-RACF performs the access authorization and resource change of the multicast-side resource change on the access side.
  • the A-RACF also requests the core network multicast bearer resource change from the SPDF/C-RACF.
  • the A-RACF returns the result response of the resource change to the IP EDGE/AN.
  • the method includes the following steps: (1) The IP EDGE/AN receives a request for the user to change the multicast source address or receives another signaling message that causes a resource change, and obtains the user IP address from the request, and It is possible to obtain the multicast source address or other QoS information requesting the change.
  • the IP EDGE/AN sends a request for a change of the multicast bearer resource to the A-RACF.
  • the IP address or identifier of the user must be carried in the request.
  • the changed multicast source address or other QoS information can be optionally carried.
  • the A-RACF performs the access authorization and resource change of the access side multicast resource change on the access side according to the access side policy and the resource status.
  • the A-RACF may also request the core network multicast bearer resource change from the SPDF/C-RACF, that is, perform steps 4-6.
  • the A-RACF initiates a request to change the multicast resource to the SPDF/C-RACF, and the information carried in the request is consistent with the second step.
  • SPDF/C-RACF authorizes to change the core network side multicast resources according to the core network resource status.
  • SPDF/C-RACF returns the multicast resource change authorization response.
  • the A-RACF returns a final authorization response to the IP EDGE/AN according to the access side, or the multicast resource change result of the access side and the core side.
  • Embodiment 3 When the A-RACF is used as the final policy decision point, when the 7
  • the IP EDGE/AN When the IP EDGE/AN receives a request from the user to leave a multicast group or detects that the user has left the multicast group abnormally, the IP EDGE/AN obtains the multicast group address and the user IP address that the user desires to leave.
  • the IP EDGE/AN sends a request for releasing the multicast bearer resource to the A-RACF. If the interface between the IP EDGE/AN and the A-RACF uses the Diameter protocol, the request carries the session identifier. Otherwise, the request needs to carry the user IP address or identifier and the multicast group description information.
  • the A-RACF releases the access side multicast bearer resources. If the A-RACF determines that there are other users in the multicast group on the IP EDGE/AN, then the access network resource is released. If the user is the last user on the IP EDGE/AN to leave the multicast group, The access network and the aggregation network resources need to be released. Optionally, the A-RACF may also request to release the core network multicast bearer resources from the SPDF/C-RACF, that is, perform steps 4-6.
  • the A-RACF initiates a multicast resource release request to the SPDF/C-RACF, and the request carries the session identifier.
  • SPDF/C-RACF releases the core network side multicast resources.
  • SPDF/C-RACF returns the multicast resource release response.
  • the A-RACF returns a final response to the IP EDGE/AN according to the multicast resource release result of the access side or the access side and the core side.
  • Embodiment 4 With SPDF as the final decision point, an application request/response of multicast resources needs to be transmitted between the bearer layer network entity IP EDGE/AN and SPDF, which can be in IP.
  • the Gq. interface (used in the prior art for delivering unicast resource authorization requests/responses) is reused between EDGE/AN and SPDF, and the interface capability is extended to support the request/response delivery of multicast resources.
  • the IP EDGE/AN After receiving the request of the user to join the multicast group, the IP EDGE/AN initiates the application for multicasting the resource to the SPDF.
  • the SPDF authorizes the request, and applies for the access-side multicast bearer resource to the A-RACF.
  • the A-RACF is accessed according to the access.
  • Admittance of the access side multicast bearer resources by the side policy and the remaining resources The rights and resources are reserved, and the application result is returned to SPDF.
  • the SPDF can also apply to the C-RACF for the core network multicast bearer resource.
  • the SPDF returns a final response to the IP EDGE/AN based on the resource authorization status of the access side or the integrated network. Referring to Figure 8, the following steps are included:
  • the IP EDGE/AN receives the user's request to join the multicast group, obtains the multicast group address and the user IP address that the user desires to join, and may also obtain the multicast source address (one or more), and Source address filtering mode (such as EXCLUDE or INCLUDE).
  • multicast source address one or more
  • Source address filtering mode such as EXCLUDE or INCLUDE
  • the IP EDGE/AN sends a multicast bearer resource request to the SPDF, and the request carries the user IP address or identifier and the multicast stream description information.
  • the description of the multicast stream must include the multicast group D address, optionally including the multicast source address (one or more), and the source address filtering mode (such as EXCLUDE or INCLUDE). If the IP EDGE/AN is configured with the bandwidth resource information required by the multicast group, it needs to be carried in the request.
  • SPDF performs service authorization on the request, and optionally, the SPDF may request the C-RACF to authorize the core network multicast bearer resource, that is, perform steps 7-9.
  • the SPDF sends a request for requesting the multicast bearer resource to the A-RACF, and the information carried in the request is consistent with the information contained in the request in the second step.
  • the A-RACF After receiving the request for the multicast bearer resource sent by the SPDF, the A-RACF performs the access-side multicast bearer resource access authorization and resource reservation according to the access-side policy and the resource. If yes, the network resources of the access network are integrated to perform access authorization and resource reservation for the access network multicast bearer resources. If not, the network resources of the integrated access network and the access aggregation network are connected to the access network. Incoming aggregation network multicast bearer resource admission authorization and resource reservation.
  • A-RACF returns the authorization result, indicating whether to authorize through the multicast resource.
  • the SPDF applies to the C-RACF for the core network multicast bearer resource; (8) and the C-RACF authorize the request according to the core network resource status;
  • C-RACF returns an authorization response to SPDF;
  • SPDF returns a response to the bearer layer according to the multicast resource authorization result of the access side or the access side and the core side.
  • Embodiment 5 With SPDF as the final decision point, it is necessary to pass a multicast resource change request/response between the bearer layer network entity IP EDGE/AN and SPDF, which can be in IP.
  • the Gq interface (used in the prior art to pass unicast resource authorization change request/response) is reused between EDGE/AN and SPDF, and the interface capability is extended to support the transfer of request/response of multicast resources.
  • the IP EDGE/AN When the IP EDGE/AN receives a request for the user to change the multicast source address or other signaling message that causes a resource change, the IP EDGE/AN initiates a change request for the multicast bearer resource to the SPDF, and the SPDF authorizes the request and sends the request to the A - The RACF requests to change the access side multicast 7-load resource.
  • the SPDF can also request the C-RACF to change the core network multicast bearer resources.
  • SPDF returns the result response of the resource change to IP EDGE/AN. See Figure 9, which includes the following steps:
  • the IP EDGE/AN receives the user's request to change the multicast source address or other signaling message that causes the resource change.
  • the user IP address is obtained from the message, and the changed multicast source address or other QoS information may also be obtained. .
  • the IP EDGE/AN sends a multicast bearer resource change request to the SPDF.
  • the request carries the user IP address, optionally carrying the changed multicast source address or other QoS information.
  • the SPDF sends a multicast resource change request to the A-RACF, and the information carried in the request is the same as step 2.
  • the A-RACF After receiving the resource change request sent by the SPDF, the A-RACF performs the access authorization and resource change of the access side multicast bearer resource change according to the access side policy and the resource status.
  • A-RACF returns the authorization result of the multicast resource change.
  • the SPDF requests the C-RACF to perform a core network multicast bearer resource change
  • C-RACF authorizes to change the core network multicast bearer resources according to the core network resource status; (8), C-RACF returns the response of the multicast bearer resource change;
  • the SPDF returns a final response to the IP EDGE/AN according to the authorization result of the access side, or the multicast resource change of the access side and the core side.
  • Embodiment 6 With SPDF as the final decision point, it is necessary to pass a multicast resource release request/response between the bearer layer network entity IP EDGE/AN and SPDF, which can be in IP.
  • the Gq. interface is reused between EDGE/AN and SPDF (in the prior art for delivering unicast resource authorization requests/responses), and the interface capability is extended to support the delivery of multicast resource release requests/responses.
  • the IP EDGE/AN When the IP EDGE/AN receives the request to leave the multicast group sent by the user, the IP EDGE/AN initiates a multicast resource release request to the SPDF, and the SPDF requests the A-RACF to release the access side multicast bearer resource, and the A-RACF returns. In response, optionally, the SPDF may also request the C-RACF to release the core network multicast bearer resources. Finally, the SPDF returns a resource release response to the IP EDGE/AN. See Figure 10, which includes the following steps:
  • the IP EDGE/AN receives the user's request to leave the multicast group, and obtains the multicast group address and the user IP address that the user desires to leave.
  • IP EDGE/AN sends a multicast bearer resource release request to SPDF, if IP
  • the interface between the EDGE/AN and the SPDF uses the Diameter protocol, and the request carries the session identifier. Otherwise, the request needs to carry the user IP address or identifier and the multicast group description information.
  • the SPDF sends a multicast resource release request to the A-RACF, requesting the A-RACF to release the access side multicast resource, where the request carries the session identifier.
  • the A-RACF After receiving the resource release request sent by the SPDF, the A-RACF releases the corresponding multicast resource. Specifically, the A-RACF determines whether the multicast stream is not used by the user on the corresponding IP EDGE/AN. If yes, the network resources occupied by the access network and the corresponding multicast stream of the access aggregation network are released. Only the network resources occupied by the corresponding multicast streams in the access network are released.
  • A-RACF returns the multicast resource release result.
  • the SPDF requests the C-RACF to release the core network multicast bearer resources; (7) The C-RACF releases the core network multicast bearer resources;
  • C-RACF returns the resource release response
  • the SPDF returns a final response to the IP EDGE/AN according to the release result of the multicast resource on the access side or the access side and the core side.
  • Embodiment 7 It can be seen from the above embodiment that due to the difference between multicast and unicast technology,
  • SPDF and/or A-RACF need to increase the processing capability of multicast resource-related requests (application, release, or change) for multicast features, in order to finally allow RACS to complete control over multicast bearer resources.
  • An example of an algorithm for A-R ACF to process multicast resource related requests is given below.
  • (S, G) represents a multicast stream
  • S is the multicast source address
  • G is the multicast group address
  • N the number of access users served by (S, G) on the IP EDGE/AN.
  • the A-RACF needs to store the correspondence between the multicast stream (S, G) of all requested resources and the number of users (N) receiving the multicast stream, and update the N in real time to determine the process of processing the multicast resource request.
  • the algorithm for A-RACF processing multicast resource related requests is shown in Figure 11. When A-RACF receives a multicast resource request from SPDF, it determines the type of request:
  • the multicast resource management and multicast resource admission control functions in the current LTV/BTV system architecture are generally implemented directly on the bearer layer entity.
  • this method needs to implement multicast resource management and admission control in the bearer layer entity, which leads to an increase in the complexity of the bearer layer device.
  • Many network bearer layer devices such as Ethernet switches and routers, do not support multicast resource management and admission control functions. It is difficult to implement in actual networking applications.
  • the multicast bearer resources of this method are in the bearer layer entity.
  • the unicast bearer resources are managed in the RACS. As a result, the unicast and multicast bearer resources are separated from each other in the NGN network, resulting in unicast and multicast services.
  • the network bearer resources cannot be fully shared, or a complex network bearer resource synchronization mechanism needs to be introduced to implement network resource sharing between unicast and multicast services.
  • it is proposed that the use of the RACS in the NGN network to implement the control of the multicast bearer resource is a better solution to the above problem.
  • the current RACS architecture only supports the management of unicast bearer resources, and has not been able to control multicast bearer resources.
  • the bearer layer network entity after receiving the control request of the multicast bearer resource by the user, the bearer layer network entity forwards the request to the RACS; the network entity in the RACS receives the multicast bearer resource from the bearer layer network entity. After the request message is controlled, the multicast bearer resource control is performed on the request, and a control response is returned to the bearer layer network entity.
  • the RACS can support the resource control of the multicast service flow, so as to avoid the management and admission control function of the multicast resource in the bearer layer entity, and the centralized management of the multicast and unicast resources to ensure unicast and The multicast service fully shares the bearer resources. Therefore, the service quality of the IPTV multicast service is improved, and the IPTV multicast service can be smoothly carried out.
  • the foregoing storage medium includes: a medium that can store program codes, such as a ROM, a RAM, a magnetic disk, or an optical disk.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Mobile Radio Communication Systems (AREA)

Description

一种组播承载资源的控制方法、 装置及系统
技术领域
本发明涉及通信领域和网络领域，特别是涉及组播承载资源的控制方法、 装置及系统。 背景技术
互联网协议电视 ( Internet Protocol Television , 以下筒称： IPTV ) 业 务是基于宽带 IP网络开展的、 以流媒体为主的业务。 与传统的电视相比 较， IPTV能够提供更加丰富灵活的业务， 提供一个综合的 IPTV增值业务 平台， 实现通信、 数据、 视频、 音频等业务。 IPTV中的直播 /广播电视业 务（LTV/BTV )需要将一个源节点产生的数据发送到多个目的节点， 即点 对多点的通信。 目前对点对多点通信最有效的解决方案是组播技术， 它能 有效地利用网络带宽， 避免带宽资源浪费。
相关技术一、 为了支撑组播技术， 在 TISPAN ( Telecommunication and
Internet Converged Services and Protocols for Advanced Networking )中对资 源准入控制子系统 ( Resource and Admission Control Subsystem, 以下筒称： RACS ) 架构进行了详细阐述。
RACS通过实行资源接纳控制， 向上对业务层屏蔽传送网络的具体细 节，支持业务控制与传送功能相分离，向下感知传送网络的资源使用情况， 确保正确合理地使用传送网络资源， 从而保证业务的服务质量， 并防止带 宽和业务被盗用的现象发生。 RACS的功能架构图， 参见图 1所示， 图中 主要网元介绍如下：
基于业务的策略决策功能（ Service-based Policy Decision Function, 以 下筒称： SPDF ) 向应用层提供统一的接口， 屏蔽底层网络拓朴和具体的 接入类型， 提供基于业务的策略控制。 SPDF根据应用功能 （Application Function, 以下筒称： AF ) 的请求选择本地策略， 并将请求映射成互联网 协议服务质量 ( Internet Protocol Quality of Sevice , 以下筒称： IPQoS ) 参 数， 发送给接入侧资源和准入控制功能 ( Access-Resource and Admission Control Function , 以下筒称： A-RACF )和边界网关功能（ Border Gateway Function , 以下筒称： BGF ) , 以请求相应的资源。
A-RACF位于接入网中， 具有接纳控制和网络策略汇聚的功能。
A-RACF从 SPDF接收请求， 然后基于所保存的策略实现接纳控制， 接受 或拒绝对传送资源的请求。 A-RACF通过 e4参考点从网络附着子系统 ( (Network Attachment Subsystem , 以下筒称： NASS ) 获得网络附着信 息和用户服务质量（Quality of Service, 以下筒称： QoS )清单信息， 从而 可以根据网络位置信息（例如接入用户的物理节点的地址）确定可用的网 络资源， 同时在处理资源分配请求时参考用户 QoS清单信息。
在传送层中包含 3种功能实体， 其中 BGF是边界网关， 可位于接入 网和核心网之间 （实现核心边界网关功能） ， 也可以位于两个核心网之间 (实现互联边界网关功能） 。 BGF在 SPDF的控制下完成网络地址转换 ( Network Address Translation, 以下筒称： NAT ) 、 门控、 QoS标记、 带 宽限制、使用测量以及资源同步功能。资源控制执行功能（ Resource Control Enforcement Function, 以下筒称： RCEF )实施 A-RACF通过 Re参考点传 送过来的接入运营商定义的二层 /三层 （L2/L3 )媒体流策略， 完成门控、 QoS标记、 带宽限制等功能。 二层终结功能（L2TF )是接入网中终结二层 连接的功能实体。 RCEF和 L2TF是两个不同的功能实体， 通常在物理设 备 IP边缘 ( IP EDGE ) 上一起实现。
另外， 在最新发布的 RACS R2 的 draft 中， 定义了一个新的功能 C-RACF ( Core-RACF ) , 位于核心网内， 进行资源准入控制。
相关技术二、 为方便后续对组播承载资源控制的描述， 此处将承载层 网络划分为三段： 接入网、 接入汇聚网和核心网， 参见图 2所示。 其中 UE(用户设备）到准入控制执行节点（可能是 AN( Acces Node )或 IP EDGE ) 之间称为接入网段， 此节点到核心边界节点之间称为接入汇聚网， 核心边 界节点以外称为核心网。 11) SPDF将资源授权最终结果返回给 AF。 发明人在发明过程中发现， 目前 IPTV组播业务已实现在传统网络中的 运营， 但在 RACS中， 尚未实现对组播承载资源的有效控制。 发明内容
本发明实施例提供组播承载资源的控制方法、 装置及系统， 以实现基 于 RACS对组播承载资源的控制。
本发明实施例的方法包括下列步骤： 资源和准入控制网络实体接收来 自承载层网络实体的组播承载资源的控制请求； 资源和准入控制网络实体 对该请求进行组播承载资源控制。
本发明实施例的网络实体， 位于 RACS中， 包括： 接收单元， 用于接 收来自承载层网络实体的组播承载资源的控制请求； 控制单元， 用于对接 收单元收到的请求进行组播承载资源控制。
本发明实施例的组播承载资源的控制系统， 包括： 承载层网络实体， 用于发出组播承载资源的控制请求； RACS中的网络实体， 用于接收来自 承载层网络实体的组播承载资源的控制请求， 并对该请求进行组播承载资 源控制。
本发明的实施例中， 承载层网络实体收到用户对组播承载资源的控制请 求后， 将该请求转发到 RACS中； RACS中的网络实体接收来自承载层网络实 体的组播承载资源的控制请求后， 对该请求进行组播承载资源控制。 使得 RACS可以支持对组播业务流的资源控制，这样可以避免在承载层实体引入组 播资源的管理和准入控制功能， 同时可以实现组播和单播资源的集中统一管 理， 保证单播和组播业务对承载资源的充分共享。 附图说明
图 1为现有 RACS的功能架构图；
图 2为现有将承载层网络划分为三段的示意图；
图 3为本发明实施例的组播承载资源的控制方法的步骤流程图； 图 4为本发明实施例的组播承载资源的控制装置中 RACS网络实体的 结构示意图；
图 5为本发明实施例 1组播承载资源的控制方法的流程图；
图 6为本发明实施例 2组播承载资源的控制方法的流程图；
图 7为本发明实施例 3组播承载资源的控制方法的流程图；
图 8为本发明实施例 4组播承载资源的控制方法的流程图；
图 9为本发明实施例 5组播承载资源的控制方法的流程图；
图 10为本发明实施例 6组播承载资源的控制方法的流程图； 图 11为本发明实施例 7组播承载资源的控制方法的流程图。 具体实施方式
为了应用 RACS实现对组播承载资源的控制， 本发明实施例提出一种 运用 RACS控制组播承载资源的方案，使得 RACS可以支持对组播业务流 的资源控制， 从而保证了 IPTV组播业务的顺利开展。
基于上述目的， 本发明实施例提供了一种组播承载资源的控制方法， 参见图 3所示， 包括下列步骤：
Sl、 RACS中的网络实体接收来自承载层网络实体的组播承载资源的 控制请求。
要实现在 RACS对组播承载资源的控制， 就需要承载层实体（可以是 AN或 IP EDGE )在收到用户加入组播组的请求消息、 更改资源请求消息 或释放资源请求消息后，主动向 RACS发起相应的组播承载资源控制请求， 从而将组播承载资源的控制转入 RACS执行。 S2、 RACS中的网络实体对该请求进行组播承载资源控制。 根据用户发起的控制请求不同， RACS中的网络实体对承载层网络实 体发来的请求进行组播承载资源控制并返回控制响应， 存在以下情况： 情况一、 RACS中的网络实体接收来自承载层网络实体的申请组播承 载资源的消息； RACS中的网络实体对该请求进行组播承载资源准入授权 和资源预留， 并向该承载层网络实体返回资源申请结果响应。
具体的， 若 RACS中与该承载层网络实体交互的具体网络实体为 A-RACF , 则 A-RACF接收来自承载层网络实体的申请组播承载资源的请 求后， 对该请求进行接入侧组播承载资源准入授权和资源预留， 并根据接 入侧的申请结果， 向该承载层网络实体返回资源申请结果响应。 或者， A-RACF接收来自承载层网络实体的申请组播承载资源的请求后， 对该请 求进行接入侧组播承载资源准入授权和资源预留， 还向 SPDF或 C-RACF 申请核心网组播承载资源， 并根据接入侧和核心网的申请结果， 向该承载 层网络实体返回资源申请结果响应。
具体的， 若 RACS中与该承载层网络实体交互的具体网络实体为
SPDF, 则 SPDF接收来自承载层网络实体的申请组播承载资源的请求后， 向 A-RACF申请接入侧组播承载资源， 并根据接入侧的申请结果， 向该承 载层网络实体返回资源申请结果响应。 或者， SPDF接收来自承载层网络 实体的申请组播承载资源的请求后，向 A-RACF和 C-RACF分别申请接入 侧和核心网组播承载资源， 并根据接入侧和核心网的申请结果， 向该承载 层网络实体返回资源申请结果响应。
情况二、 RACS中的网络实体接收来自承载层网络实体的更改组播承 载资源的消息； RACS中的网络实体对该请求进行组播承载资源更改的准 入授权和资源更改， 并向该承载层网络实体返回资源更改结果响应。
具体的， 若 RACS中与该承载层网络实体交互的具体网络实体为
A-RACF , 则 A-RACF接收来自承载层网络实体的更改组播承载资源的请 求后， 对该请求进行接入侧组播 7|载资源更改的准入授权和资源更改， 并 根据接入侧的更改结果， 向该承载层网络实体返回资源更改结果响应。 或 者 A-RACF接收来自承载层网络实体的更改组播承载资源的请求后，对该 请求进行接入侧组播 7?载资源更改的准入授权和资源更改， 还向 SPDF或 C-RACF请求更改核心网组播承载资源， 并根据接入侧和核心网的更改结 果， 向该承载层网络实体返回资源更改结果响应。
具体的， 若 RACS中与该承载层网络实体交互的具体网络实体为 SPDF, 则 SPDF接收来自承载层网络实体的更改组播承载资源的请求后， 向 A-RACF请求更改接入侧组播承载资源， 并根据接入侧的更改结果， 向 该承载层网络实体返回资源更改结果响应。 或者 SPDF接收来自承载层网 络实体的更改组播 7|载资源的请求后，向 A-RACF和 C-RACF分别请求进 行接入侧和核心网组播 7|载资源更改， 并根据接入侧和核心网的更改结 果， 向该承载层网络实体返回资源更改结果响应。
情况三、 RACS中的网络实体接收来自承载层网络实体的释放组播承 载资源的请求消息； RACS中的网络实体释放相应的组播承载资源， 并向 该承载层网络实体返回释放结果响应。
具体的， 若 RACS中与该承载层网络实体交互的具体网络实体为 A-RACF , 则 A-RACF接收来自承载层网络实体的释放组播承载资源的请 求后， 释放接入侧的组播承载资源， 并根据接入侧的释放结果， 向该承载 层网络实体返回释放结果响应。或者 A-RACF接收来自承载层网络实体的 释放组播承载资源的请求后， 释放接入侧的组播承载资源， 还向 SPDF或 C-RACF请求释放核心网组播承载资源， 并根据接入侧和核心网的释放结 果， 向该承载层网络实体返回释放结果响应。
具体的， 若 RACS中与该承载层网络实体交互的具体网络实体为 SPDF, 则 SPDF接收来自承载层网络实体的释放组播承载资源的请求后， 向 A-RACF请求释放接入侧的组播承载资源， 并根据接入侧的释放结果， 向该承载层网络实体返回释放结果响应。 或者 SPDF接收来自承载层网络 实体的释放组播承载资源的请求后，向 A-RACF和 C-RACF分别请求释放 接入侧和核心网的组播承载资源， 并根据接入侧和核心网的释放结果， 向 该承载层网络实体返回释放结果响应。
本发明实施例还提供了一种网络实体， 其位于 RACS中， 具体可为
A-RACF或 SPDF, 参见图 4所示， 其包括： 接收单元、 控制单元； 进一 步还可包括： 响应单元。
接收单元， 用于接收来自承载层网络实体的组播承载资源的控制请 求；
控制单元， 用于对接收单元收到的请求进行组播承载资源控制； 响应单元， 用于向发起该请求的承载层网络实体返回控制响应。 本发明实施例还提供了一种组播承载网络， 其包括： 承载层网络实体 和 RACS中的网络实体。
承载层网络实体， 用于发出组播承载资源的控制请求；
RACS中的网络实体， 用于接收来自承载层网络实体的组播承载资源 的控制请求， 并对该请求进行组播承载资源控制， 以及向所述承载层网络 实体返回控制响应。 具体的， RACS中的网络实体对所述请求进行接入侧 组播承载资源的控制， 或者对所述请求进行接入侧和核心网组播承载资源 的控制。
以下通过 6个实施例具体描述。
实施例 1、 以 A-RACF作为最终策略决策点时， 承载层网络实体 IP EDGE或 AN收到用户的加入组播组请求后， 向 A-RACF申请组播 载资 源； A-RACF依据接入侧策略和资源情况， 进行接入侧组播承载资源准入 授权和资源预留。 可选的， A-RACF还可以向 SPDF/C-R ACF申请核心网 组播承载资源。 A-RACF根据接入侧的情况， 或综合全网申请结果将最终 响应返回给承载层。 参见图 5所示， 包括下列步骤： ( 1 ) 、 IP EDGE/AN收到用户加入组播组的请求， 从该请求中获得用 户期望加入的组播组地址和用户 IP地址， 也可能获得组播源地址 （一到 多个） ， 以及源地址过滤模式 （如 EXCLUDE or INCLUDE ) 等信息。
( 2 ) 、 IP EDGE/AN向 A-RACF发出组播承载资源的申请请求， 请 求中携带用户的 IP地址或标识以及对组播流的描述信息。 其中在组播流 的描述信息内， 必须包含组播组 D类地址， 可选包含组播源地址（一到多 个 ) , 以及源地址过滤模式 （如 EXCLUDE or INCLUDE ) 。 如果此时 IP EDGE/AN处配置有组播组所需带宽资源信息， 在请求中也需要携带。
( 3 ) 、 本步骤涉及资源授权的相关内容， 包括以下两个部分： 首先可选的， A-RACF可根据用户组播业务权限对该请求进行业务授 权。
之后， A-RACF依据接入侧策略和资源情况， 进行接入侧组播承载资 源准入授权和资源预留。具体的，如果组播承载资源请求中没有带宽信息， 贝' J A-RACF查询本地配置获得组播组所需带宽。 如果 A-RACF判断在 IP EDGE/AN上已存在该组播流， 则授权和资源预留接入网资源即可； 否则 需授权和资源预留接入网资源和汇聚网资源。
进一步可选的， A-RACF还可以向 SPDF/C-RACF申请核心网组播承 载资源， 即执行 4-6步。
( 4 ) 、 A-RACF向 SPDF/C-RACF发起核心网组播承载资源的申请， 请求中携带的信息与第 2步中相同。
( 5 ) 、 SPDF/C-RACF授权核心网侧资源。
( 6 ) 、 SPDF/C-RACF返回授权结果， 指示是否通过资源授权。
( 7 ) 、 A-RACF根据接入侧， 或接入侧和核心侧的申请结果向 IP EDGE/AN返回资源授权结果响应。
实施例 2、 以 A-RACF作为最终策略决策点时， 当 载层网络实体 IP
EDGE/AN收到用户更改组播源地址的请求或其他引发资源更改的信令消 息时， IP EDGE/AN会向 A-RACF发起组播承载资源的更改请求， A-RACF 进行接入侧的组播 7|载资源更改的准入授权和资源更改。可选的， A-RACF 还向 SPDF/C-RACF请求核心网组播承载资源更改。 最后 A-RACF向 IP EDGE/AN返回资源更改的结果响应。 参见图 6所示， 包括下列步骤： ( 1 ) 、 IP EDGE/AN收到用户更改组播源地址的请求或收到其他引发 资源更改的信令消息， 从该请求中获得用户 IP地址， 并可能获得请求更 改的组播源地址或其他 QoS信息。
( 2 ) 、 IP EDGE/AN向 A-RACF发出组播承载资源的更改请求。 请 求中需要携带用户 IP地址或标识， 可选携带更改后的组播源地址或其他 QoS信息。
( 3 ) 、 A-RACF根据接入侧策略和资源状况对该请求进行接入侧的 组播 7 载资源更改的准入授权和资源更改。 可选的， A-RACF还可向 SPDF/C-RACF请求核心网组播承载资源更改， 即执行 4-6步。
( 4 ) 、 A-RACF向 SPDF/C-RACF发起更改组播资源的请求， 请求中 携带信息与第二步一致。
( 5 ) 、 SPDF/C-RACF根据核心网资源状况授权更改核心网侧组播资 源。
( 6 ) 、 SPDF/C-RACF返回组播资源更改授权响应。
( 7 ) 、 A-RACF根据接入侧， 或接入侧和核心侧的组播资源更改结 果向 IP EDGE/AN返回最终授权响应。
实施例 3、 以 A-RACF作为最终策略决策点时， 当 7|载层网络实体 IP EDGE/AN收到用户发来的离开组播组请求或检测到用户已经异常离开组 播组时， IP EDGE/AN会向 A-RACF发起组播承载资源的释放请求， A-RACF释放接入网， 或者接入网和接入汇聚网组播承载资源。 可选的， A-RACF还可请求 SPDF/C-RACF释放核心网资源。 最后 A-RACF向 IP EDGE/AN返回资源释放响应。 参见图 7所示， 包括下列步骤： ( 1 ) 、 IP EDGE/AN收到用户离开某组播组的请求或检测到用户已经 异常离开组播组时，从该请求中获得用户期望离开的组播组地址和用户 IP 地址。
( 2 ) 、 IP EDGE/AN向 A-RACF发出组播承载资源的释放请求。 如 果 IP EDGE/AN与 A-RACF之间的接口使用 Diameter协议， 则请求中携 带会话标识即可， 否则请求中需要携带用户 IP地址或标识以及组播组描 述信息。
( 3 ) 、 A-RACF释放接入侧组播承载资源。 如果 A-RACF判断在 IP EDGE/AN上还有其他用户在该组播组内， 则释放接入网资源即可， 如果 该用户已是 IP EDGE/AN上最后一个离开组播组的用户， 则需释放接入网 和汇聚网资源。 可选的， A-RACF还可能向 SPDF/C-RACF请求释放核心 网组播承载资源， 即执行 4-6步。
( 4 ) 、 A-RACF向 SPDF/C-RACF发起组播资源释放请求， 请求中携 带会话标识。
( 5 ) 、 SPDF/C-RACF释放核心网侧组播资源。
( 6 ) 、 SPDF/C-RACF返回组播资源释放响应。
( 7 ) 、 A-RACF根据接入侧， 或接入侧和核心侧的组播资源释放结 果向 IP EDGE/AN返回最终响应。
实施例 4、 以 SPDF为最终决策点， 就需要在承载层网络实体 IP EDGE/AN与 SPDF之间传递组播资源的申请请求 /响应， 可以在 IP
EDGE/AN与 SPDF之间重用 Gq. 接口 （现有技术中用于传递单播资源授 权请求 /响应） ， 并扩展接口能力使其支持组播资源的申请请求 /响应的传 递。
IP EDGE/AN收到用户加入组播组的请求后， 向 SPDF发起组播 载 资源的申请， SPDF授权该请求， 并向 A-RACF申请接入侧组播承载资源， A-RACF根据接入侧策略和资源剩余情况进行接入侧组播承载资源准入授 权和资源预留， 同时返回申请结果给 SPDF。 可选的， SPDF还可以向 C-RACF申请核心网组播承载资源。 SPDF根据接入侧或综合全网的资源 授权情况返回最终响应返回给 IP EDGE/AN。 参见图 8所示， 包括下列步 骤：
( 1 ) 、 IP EDGE/AN收到用户的加入组播组请求， 从此消息中获得用 户期望加入的组播组地址和用户 IP地址， 也可能获得组播源地址 （一到 多个） ， 以及源地址过滤模式 （如 EXCLUDE or INCLUDE ) 等信息。
( 2 ) 、 IP EDGE/AN向 SPDF发出组播承载资源申请， 请求中携带用 户 IP地址或标识以及组播流描述信息。 其中在组播流的描述信息内， 必 须包含组播组 D类地址， 可选包含组播源地址（一到多个） ， 以及源地址 过滤模式 （如 EXCLUDE or INCLUDE ) 。 如果此时 IP EDGE/AN处配置 有组播组所需带宽资源信息， 在请求中也需要携带。
( 3 ) 、 SPDF对该请求进行业务授权， 同时可选的， SPDF可能向 C-RACF请求授权核心网组播承载资源， 即执行 7-9步。
( 4 ) 、 SPDF向 A-RACF发送申请组播承载资源的请求， 该请求中携 带的信息与第 2步的请求中包含的信息一致。
( 5 ) 、 A-RACF收到 SPDF发送的申请组播承载资源的请求后， 根据 接入侧策略和资源情况， 进行接入侧组播承载资源准入授权和资源预留。 如果存在则综合接入网的网络资源情况进行接入网组播承载资源准入授 权和资源预留， 如果不存在则综合接入网和接入汇聚网的网络资源情况进 行接入网和接入汇聚网组播承载资源准入授权和资源预留。
( 6 ) 、 A-RACF返回授权结果， 指示是否通过组播资源授权。
( 7 ) 、 可选的， SPDF向 C-RACF申请核心网组播承载资源； ( 8 ) 、 C-RACF根据核心网资源状况授权该请求；
( 9 ) 、 C-RACF向 SPDF返回授权响应； ( 10 ) 、 SPDF根据接入侧， 或接入侧和核心侧的组播资源授权结果 向承载层返回响应。
实施例 5、 以 SPDF为最终决策点， 就需要在承载层网络实体 IP EDGE/AN与 SPDF之间传递组播资源的更改请求 /响应， 可以在 IP
EDGE/AN与 SPDF之间重用 Gq接口（现有技术中用于传递单播资源授权 更改请求 /响应） ， 并扩展接口能力使其支持组播资源的更改请求 /响应的 传递。
当 IP EDGE/AN收到用户更改组播源地址的请求或其他引发资源更改 的信令消息时， IP EDGE/AN会向 SPDF发起组播承载资源的更改请求， SPDF授权该请求， 并向 A-RACF请求更改接入侧组播 7 载资源。 可选的， SPDF还可请求 C-RACF更改核心网组播承载资源。 最后 SPDF向 IP EDGE/AN返回资源更改的结果响应。 参见图 9所示， 包括下列步骤：
( 1 ) 、 IP EDGE/AN收到用户更改组播源地址的请求或其他引发资源 更改的信令消息， 从此消息中获得用户 IP地址， 也可能获得更改后的组 播源地址或其他 QoS信息。
( 2 ) 、 IP EDGE/AN向 SPDF发出组播承载资源更改请求， 请求中需 要携带用户 IP地址， 可选携带更改后的组播源地址或其他 QoS信息。
( 3 ) 、 SPDF向 A-RACF发送组播资源更改请求， 该请求中携带信息 与步骤 2相同。
( 4 ) 、 A-RACF收到 SPDF发送的资源更改请求后， 根据接入侧策略 和资源状况对该请求进行接入侧组播承载资源更改的准入授权和资源更 改。
( 5 ) 、 A-RACF返回组播资源更改的授权结果。
( 6 ) 、 可选的， SPDF向 C-RACF请求进行核心网组播承载资源更 改；
( 7 ) 、 C-RACF根据核心网资源状况授权更改核心网组播承载资源； ( 8 ) 、 C-RACF返回组播承载资源更改的响应；
( 9 ) 、 SPDF根据接入侧， 或接入侧和核心侧的组播资源更改的授权 结果向 IP EDGE/AN返回最终响应。
实施例 6、 以 SPDF为最终决策点， 就需要在承载层网络实体 IP EDGE/AN与 SPDF之间传递组播资源释放的请求 /响应， 可以在 IP
EDGE/AN与 SPDF之间重用 Gq. 接口 （现有技术中用于传递单播资源授 权请求 /响应）， 并扩展接口能力使其支持组播资源释放请求 /响应的传递。
当 IP EDGE/AN收到用户发来的离开组播组请求时， IP EDGE/AN会 向 SPDF发起组播资源释放请求， SPDF请求 A-RACF释放接入侧组播承 载资源， A-RACF返回响应， 此时可选的， SPDF还可以向 C-RACF请求 释放核心网组播承载资源。最后 SPDF向 IP EDGE/AN返回资源释放响应。 参见图 10所示， 包括下列步骤：
( 1 ) 、 IP EDGE/AN收到用户的离开组播组请求， 从此消息中获得用 户期望离开的组播组地址和用户 IP地址。
( 2 ) 、 IP EDGE/AN向 SPDF发出组播承载资源释放请求， 如果 IP
EDGE/AN与 SPDF之间的接口使用 Diameter协议， 则请求中携带会话标 识即可， 否则请求中需要携带用户 IP地址或标识以及组播组描述信息。
( 3 ) 、 SPDF向 A-RACF发送组播资源释放请求， 请求 A-RACF释 放接入侧组播资源， 该请求中携带会话标识。
( 4 ) 、 A-RACF收到 SPDF发送的资源释放请求后， 释放相应的组播 资源。 具体的， A-RACF判断该组播流在相应的 IP EDGE/AN上是否已经 没有用户使用， 如果是， 则释放接入网络和接入汇聚网络相应的组播流所 占用的网络资源， 否则仅释放接入网络中相应的组播流所占用的网络资 源。
( 5 ) 、 A-RACF返回组播资源释放结果。
( 6 ) 、 可选的， SPDF向 C-RACF请求释放核心网组播承载资源； (7) 、 C-RACF释放核心网组播承载资源；
(8) 、 C-RACF返回资源释放响应；
(9) 、 SPDF根据接入侧， 或接入侧和核心侧的组播资源释放结果向 IP EDGE/AN返回最终响应。
实施例 7、 从上述实施例中可见， 由于组播与单播技术的差异， 使得
SPDF和 /或 A-RACF需要针对组播的特点增加对组播资源相关请求（申请、 释放或更改）的处理能力，才能最终让 RACS完成对组播承载资源的控制。 现给出 A-R ACF处理组播资源相关请求的算法示例如下。
其中： （S, G) ： 代表一个组播流， S为组播源地址， G为组播组地 址； N: 在 IP EDGE/AN上的 （S, G) 所服务的接入用户数。
A-RACF需要存储所有请求资源的组播流（ S, G)和接收该组播流的 用户数（N) 的对应关系， 并对 N进行实时更新， 以决定处理组播资源请 求的流程。 A-RACF处理组播资源相关请求的算法如图 11所示。当 A-RACF 收到来自 SPDF的组播资源请求之后， 判断请求的类型：
a) 申请组播资源。 A-RACF判断是否已存在 （S, G) 组播流， 如果 没有， 则为此（S, G)创建相应的 N (N=l ) , 同时授权接入和接入汇聚 网段的组播资源； 如果已存在对应的 N, 则 N=N+l, 授权接入网段的组 播资源。
b)释放组播资源。 A-RACF判断 （S, G)对应的 （ N= N-1 )后 N是 否等于 0, 如果等于 0, 则删除（S, G) 与 N的对应关系， 授权释放接入 和接入汇聚网段的组播资源；如果 N不为 0,授权释放接入网段组播资源。
c) 更改组播资源。 首先根据 a) 中的描述的算法申请新的组播资源， 其次根据 b) 中的描述的算法释放原有的组播资源。
综上所述， 目前的 LTV/BTV系统架构中组播资源管理和组播资源准 入控制功能一般直接在承载层实体上实现。 此方法一方面需要在承载层实 体实现组播资源的管理和准入控制， 导致承载层设备复杂度增加， 而且现 有网络很多承载层设备如以太网交换机和路由器均不支持组播资源管理 和准入控制功能， 实际组网应用中很难实施； 另一方面这种方法的组播承 载资源是在承载层实体上进行管理， 而目前在 NGN架构中， 单播承载资 源是在 RACS中进行管理的， 这样导致 NGN网络中单播和组播的承载资 源管理上互相分离， 造成单播和组播业务之间无法对网络承载资源实现充 分的共享， 或需要引入复杂的网络承载资源同步机制才能实现单播和组播 业务之间的网络资源共享。 本发明实施例中提出， NGN网络中使用 RACS 实现对组播承载资源的控制是解决上述问题的较好方案。
目前的 RACS架构仅支持对单播承载资源的管理， 尚未能够对组播承 载资源进行控制。
因此本发明的实施例中， 承载层网络实体收到用户对组播承载资源的 控制请求后， 将该请求转发到 RACS中； RACS中的网络实体接收来自承 载层网络实体的组播承载资源的控制请求消息后， 对该请求进行组播承载 资源控制， 并向所述承载层网络实体返回控制响应。 使得 RACS可以支持 对组播业务流的资源控制， 这样可以避免在承载层实体引入组播资源的管 理和准入控制功能， 同时可以实现组播和单播资源的集中统一管理， 保证 单播和组播业务对承载资源的充分共享。 从而提高了 IPTV组播业务的服 务质量， 使得 IPTV组播业务可以顺利开展。
本领域普通技术人员可以理解： 实现上述方法实施例的全部或部分步 骤可以通过程序指令相关的硬件来完成， 前述的程序可以存储于一计算机 可读取存储介质中， 该程序在执行时， 执行包括上述方法实施例的步骤， 而前述的存储介质包括： ROM、 RAM, 磁碟或者光盘等各种可以存储程 序代码的介质。
发明的精神和范围。 这样， 倘若本发明的这些修改和变型属于本发明权利要 求及其等同技术的范围之内， 则本发明也意图包含这些改动和变型在内。

Claims

权 利 要 求
1、 一种组播承载资源的控制方法， 其特征在于， 包括下列步骤： 资源和准入控制网络实体接收来自承载层网络实体的组播承载资源 的控制请求；
所述资源和准入控制网络实体对该请求进行组播承载资源控制。
2、 如权利要求 1所述的方法， 其特征在于， 所述资源和准入控制网 络实体接收来自承载层网络实体的申请组播承载资源的消息；
所述资源和准入控制网络实体对该请求进行组播承载资源准入授权 和资源预留， 并向该承载层网络实体返回资源申请结果响应。
3、 如权利要求 2所述的方法， 其特征在于， 所述 RACS中的接入侧 资源和准入控制功能实体 A-RACF接收来自承载层网络实体的申请组播 承载资源的请求后， 对该请求进行接入侧组播承载资源准入授权和资源预 留， 并根据接入侧的申请结果， 向该承载层网络实体返回资源申请结果响 应。
4、 如权利要求 2所述的方法， 其特征在于， 所述 RACS中的接入侧 资源和准入控制功能实体 A-RACF接收来自承载层网络实体的申请组播 承载资源的请求后， 对该请求进行接入侧组播承载资源准入授权和资源预 留， 还向基于业务的策略决策功能实体 SPDF或核心资源和准入控制功能 实体 C-RACF申请核心网组播承载资源， 并根据接入侧和核心网的申请结 果， 向该承载层网络实体返回资源申请结果响应。
5、 如权利要求 3或 4所述的方法， 其特征在于， A-RACF在进行组 播承载资源准入授权和资源预留之前， 先根据组播业务权限对该申请组播 承载资源的请求进行业务授权。
6、 如权利要求 2所述的方法， 其特征在于， 所述 RACS中的 SPDF 接收来自承载层网络实体的申请组播承载资源的请求后，向 A-RACF申请 接入侧组播承载资源， 并根据接入侧的申请结果， 向该承载层网络实体返 回资源申请结果响应。
7、 如权利要求 2所述的方法， 其特征在于， 所述 RACS中的 SPDF 接收来自承载层网络实体的申请组播承载资源的请求后， 向 A-RACF和 C-RACF分别申请接入侧和核心网组播承载资源， 并根据接入侧和核心网 的申请结果， 向该承载层网络实体返回资源申请结果响应。
8、 如权利要求 6或 7所述的方法， 其特征在于， SPDF在进行组播承 载资源的申请之前， 先根据组播业务权限对该申请组播承载资源的请求进 行业务授权。
9、 如权利要求 1所述的方法， 其特征在于， 所述资源和准入控制网 络实体接收来自承载层网络实体的更改组播承载资源的消息；
所述资源和准入控制网络实体对该请求进行组播承载资源更改的准 入授权和资源更改， 并向该承载层网络实体返回资源更改结果响应。
10、如权利要求 9所述的方法，其特征在于，所述 RACS中的 A-RACF 接收来自承载层网络实体的更改组播承载资源的请求后， 对该请求进行接 入侧组播承载资源更改的准入授权和资源更改， 并根据接入侧的更改结 果， 向该承载层网络实体返回资源更改结果响应。
11、如权利要求 9所述的方法，其特征在于，所述 RACS中的 A-RACF 接收来自承载层网络实体的更改组播承载资源的请求后， 对该请求进行接 入侧组播承载资源更改的准入授权和资源更改， 还向 SPDF或 C-RACF请 求更改核心网组播承载资源， 并根据接入侧和核心网的更改结果， 向该承 载层网络实体返回资源更改结果响应。
12、 如权利要求 9所述的方法， 其特征在于， 所述 RACS中的 SPDF 接收来自承载层网络实体的更改组播承载资源的请求后，向 A-RACF请求 更改接入侧组播承载资源， 并根据接入侧的更改结果， 向该承载层网络实 体返回资源更改结果响应。
13、 如权利要求 9所述的方法， 其特征在于， 所述 RACS中的 SPDF 接收来自承载层网络实体的更改组播承载资源的请求后， 向 A-RACF和 C-RACF分别请求进行接入侧和核心网组播承载资源更改， 并根据接入侧 和核心网的更改结果， 向该承载层网络实体返回资源更改结果响应。
14、 如权利要求 1所述的方法， 其特征在于， 所述资源和准入控制网 络实体接收来自承载层网络实体的释放组播承载资源的请求消息；
所述资源和准入控制网络实体释放相应的组播承载资源， 并向该承载 层网络实体返回释放结果响应。
15、 如权利要求 14所述的方法， 其特征在于， RACS中的 A-RACF 接收来自承载层网络实体的释放组播承载资源的请求后， 释放接入侧的组 播承载资源， 并根据接入侧的释放结果， 向该承载层网络实体返回释放结 果响应。
16、 如权利要求 14所述的方法， 其特征在于， RACS中的 A-RACF 接收来自承载层网络实体的释放组播承载资源的请求后， 释放接入侧的组 播承载资源， 还向 SPDF或 C-RACF请求释放核心网组播承载资源， 并根 据接入侧和核心网的释放结果， 向该承载层网络实体返回释放结果响应。
17、 如权利要求 14所述的方法， 其特征在于， RACS中的 SPDF接收 来自承载层网络实体的释放组播承载资源的请求后，向 A-RACF请求释放 接入侧的组播承载资源， 并根据接入侧的释放结果， 向该承载层网络实体 返回释放结果响应。
18、 如权利要求 14所述的方法， 其特征在于， RACS中的 SPDF接收 来自承载层网络实体的释放组播承载资源的请求后， 向 A-RACF和
C-RACF分别请求释放接入侧和核心网的组播承载资源， 并根据接入侧和 核心网的释放结果， 向该承载层网络实体返回释放结果响应。
19、 一种网络实体， 位于 RACS中， 其特征在于， 包括：
接收单元， 用于接收来自承载层网络实体的组播承载资源的控制请 求；
控制单元， 用于对接收单元收到的请求进行组播承载资源控制。
20、 如权利要求 19所述的实体， 其特征在于， 所述实体还包括： 响 应单元， 用于向发起该请求的承载层网络实体返回控制响应。
21、 如权利要求 19或 20所述的实体， 其特征在于， 该网络实体为 A-RACF或 SPDF。
22、 一种组播承载资源的控制系统， 其特征在于， 包括：
承载层网络实体， 用于发出组播承载资源的控制请求；
RACS中的网络实体， 用于接收来自承载层网络实体的组播承载资源 的控制请求， 并对该请求进行组播承载资源控制。
23、 如权利要求 22所述的组播承载资源的控制系统， 其特征在于， 所述 RACS中的网络实体对所述请求进行接入侧组播承载资源的控制，或者对所述 请求进行接入侧和核心网组播承载资源的控制。
PCT/CN2008/070904 2007-06-13 2008-05-07 Procédé, dispositif et système pour commander une ressource de multidiffusion WO2008151528A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
EP08734259A EP2081323A4 (en) 2007-06-13 2008-05-07 METHOD, DEVICE AND SYSTEM FOR CONTROLLING MULTICAST RESOURCE
JP2010500058A JP4787376B2 (ja) 2007-06-13 2008-05-07 マルチキャストベアラリソースを制御するための方法、装置、およびシステム
US12/428,771 US8264998B2 (en) 2007-06-13 2009-04-23 Method, apparatus and system for controlling multicast bearer resources

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN200710111019.3 2007-06-13
CN2007101110193A CN101325500B (zh) 2007-06-13 2007-06-13 一种组播承载资源的控制方法及系统

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US12/428,771 Continuation US8264998B2 (en) 2007-06-13 2009-04-23 Method, apparatus and system for controlling multicast bearer resources

Publications (1)

Publication Number Publication Date
WO2008151528A1 true WO2008151528A1 (fr) 2008-12-18

Family

ID=40129237

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2008/070904 WO2008151528A1 (fr) 2007-06-13 2008-05-07 Procédé, dispositif et système pour commander une ressource de multidiffusion

Country Status (5)

Country Link
US (1) US8264998B2 (zh)
EP (1) EP2081323A4 (zh)
JP (1) JP4787376B2 (zh)
CN (1) CN101325500B (zh)
WO (1) WO2008151528A1 (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010233174A (ja) * 2009-03-30 2010-10-14 Kddi Corp ルータ、ネットワークシステムおよび通信方法

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101753453B (zh) * 2009-12-23 2013-02-27 中兴通讯股份有限公司 一种分组传送网环网的组网方法
CN102378115A (zh) * 2010-08-16 2012-03-14 杭州华三通信技术有限公司 组播接入控制方法、系统和装置
US9667485B2 (en) * 2011-10-04 2017-05-30 Juniper Networks, Inc. Methods and apparatus for a self-organized layer-2 enterprise network architecture
US9173073B2 (en) * 2011-12-19 2015-10-27 Motorola Solutions, Inc. Method and apparatus for processing group event notifications and providing group policy in a communication system
CN108377365B (zh) * 2018-02-08 2020-03-24 江苏恒信和安电子科技有限公司 基于视频安全接入路径的视频监控系统

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1674550A (zh) * 2004-03-24 2005-09-28 华为技术有限公司 一种组播业务的实现方法
CN1863149A (zh) * 2005-09-02 2006-11-15 华为技术有限公司 实现一组特定流的QoS控制的方法
CN1925419A (zh) * 2005-09-02 2007-03-07 华为技术有限公司 资源接纳控制处理方法
CN101030921A (zh) * 2006-03-02 2007-09-05 华为技术有限公司 一种组播控制系统和方法

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SE0400340D0 (sv) * 2004-02-11 2004-02-11 Ericsson Telefon Ab L M Method in a communication system
CN100426815C (zh) * 2004-09-08 2008-10-15 华为技术有限公司 一种ngn中的资源和准入控制子系统及方法
EP2101521B1 (en) * 2005-02-16 2011-04-13 Panasonic Corporation Support of mobile terminals in a multicast or broadcast service comprising a plurality of bearers
CN100461951C (zh) * 2005-11-11 2009-02-11 华为技术有限公司 一种组播切换方法和设备

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN1674550A (zh) * 2004-03-24 2005-09-28 华为技术有限公司 一种组播业务的实现方法
CN1863149A (zh) * 2005-09-02 2006-11-15 华为技术有限公司 实现一组特定流的QoS控制的方法
CN1925419A (zh) * 2005-09-02 2007-03-07 华为技术有限公司 资源接纳控制处理方法
CN101030921A (zh) * 2006-03-02 2007-09-05 华为技术有限公司 一种组播控制系统和方法

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2081323A4 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2010233174A (ja) * 2009-03-30 2010-10-14 Kddi Corp ルータ、ネットワークシステムおよび通信方法

Also Published As

Publication number Publication date
US8264998B2 (en) 2012-09-11
JP4787376B2 (ja) 2011-10-05
EP2081323A1 (en) 2009-07-22
EP2081323A4 (en) 2009-10-28
US20090207841A1 (en) 2009-08-20
CN101325500B (zh) 2012-12-12
CN101325500A (zh) 2008-12-17
JP2010523026A (ja) 2010-07-08

Similar Documents

Publication Publication Date Title
EP2164273A1 (en) Method, system and device of multicast resource control
EP2124385B1 (en) Method, device and system for multicast service authorization controlling
US8488603B2 (en) Method, apparatus, and system for implementing multicast services
WO2006094446A1 (fr) Procede pour obtenir la reservation de ressources pour un mode de demande d'agent dans ngn
WO2007121686A1 (fr) Système et procédé pour réaliser un mécanisme de négociation de qualité de service
US8072897B2 (en) Method, system and device for selecting edge connection link across different management domain networks
WO2009026844A1 (fr) Procédé, système et appareil de commande d'admission multidiffusion ou monodiffusion
WO2009114976A1 (zh) 资源接纳控制方法和系统
US8526304B2 (en) Processing method for resource request in NGN
WO2011022893A1 (zh) 一种资源接纳控制系统间的交互方法和装置
WO2008151528A1 (fr) Procédé, dispositif et système pour commander une ressource de multidiffusion
WO2007025461A1 (fr) Procede et systeme de gestion de la qos d'un ensemble de flux speciaux
WO2008025205A1 (fr) Procédé et système d'application de service et unité d'agence d'application de service
WO2008046336A1 (fr) Système et procédé permettant un contrôle d'accès réparti dans un service multidiffusion
WO2008017226A1 (fr) Système et procédé de commande de multidiffusion
WO2009024096A1 (fr) Appareil de gestion de ressources, procédé et système
US20100329266A1 (en) System and a Method for Resource Access Control
WO2009132492A1 (zh) 一种racs支持移动ip的系统及方法
WO2007033612A1 (fr) Systeme et procede de commande de ressource du reseau d'acces
WO2009100625A1 (zh) 资源接纳控制系统中的策略决策功能实体的选择方法
WO2011032374A1 (zh) 批发场景下的拉模式资源接纳控制方法和系统
WO2011044811A1 (zh) 一种接纳控制系统及方法
WO2008049355A1 (fr) Procédé, dispositif et système de synchronisation de données utilisateur dans un réseau nouvelle génération
WO2011127760A1 (zh) 一种漫游场景下的资源策略决策方法和系统
WO2008025267A1 (fr) Procédé, système, unité de commande d'admission et de ressource pour établir le service de multidiffusion

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08734259

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2008734259

Country of ref document: EP

WWE Wipo information: entry into national phase

Ref document number: 3133/KOLNP/2009

Country of ref document: IN

ENP Entry into the national phase

Ref document number: 2010500058

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE