WO2019007387A1

WO2019007387A1 - Bandwidth sharing among multiple flows

Info

Publication number: WO2019007387A1
Application number: PCT/CN2018/094632
Authority: WO
Inventors: Hui Yang; Susana Fernandez Alonso; Juying GAN; Ignacio RIVAS MOLINA; Wenliang Xu; Jinyin Zhu
Original assignee: Telefonaktiebolaget Lm Ericsson (Publ)
Priority date: 2017-07-05
Filing date: 2018-07-05
Publication date: 2019-01-10

Abstract

The embodiments herein relate to a method for sharing bandwidth among multiple uplink and/or downlink service data flows, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component, the method comprising: receiving a message indicating support of bandwidth sharing; and generating at least one Policy and Charging Control (PCC) rule, the at least one PCC rule indicates bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component. The embodiments enable the use case where multiple uplink and/or downlink service data flows should share a common bandwidth, to ensure more efficient network resource usage.

Description

BANDWIDTH SHARING AMONG MULTIPLE FLOWS

Technical Field

Embodiments herein relate generally to the technical field of communication. More particularly, the embodiments herein relate to methods and apparatuses for sharing bandwidth among multiple uplink and/or downlink service data flows (SDFs) .

Background

The third Generation Partnership Project (3GPP) has defined a Policy and Charging Control (PCC) architecture to allow the Quality of Service (QoS) differentiation and charging differentiation per service data flow. This is achieved by matching the user plane packets to certain PCC rules.

The Policy and Charging Rule Function (PCRF) is a functional element which is responsible for activating the appropriate PCC rule for Packet Data Network (PDN) connection. It encompasses policy control decision and flow based charging control functionalities. The PCRF provides network control regarding the service data flow detection, gating, QoS and flow based charging (except credit management) towards a Policy Control and Enforcement Function (PCEF) . The PCRF receives session and media related information from an Application Function (AF) and informs the AF of traffic plane events. The PCRF provisions PCC Rules to the PCEF via a Gx reference point (Gx interface) , it informs the PCEF through the use of PCC rules on the treatment of each service data flow that is under PCC control, in accordance with the PCRF policy decision (s) .

The PCEF encompasses service data flow detection (based on the filters definitions included in the PCC rules or configured in the PCEF) , as well as online and offline charging interactions and policy enforcement. The PCEF is the one handling the bearers, and the QoS enforcement on bearer level is performed according to the QoS information coming from the PCRF. This functional entity is located at the Gateway (e.g., GGSN in the GPRS case, and PDG in the WLAN case) .

The AF is an element offering applications in which service is delivered in a different layer (e.g., transport layer) from the layer (e.g. signaling layer) for which the service has been requested, the control of IP bearer resources is based on what has been negotiated. One example of the AF is a Proxy Call Session Control Function (P-CSCF) of an Internet protocol Multimedia (IM) Core Network (CN) subsystem. The AF communicates with the PCRF to transfer dynamic session information (e.g. the description of the media to be delivered in the transport layer) . This communication is performed by using the Rx interface.

When the AF sends dynamic session information to the PCRF, it can put different service data flow information into different media subcomponents within a media component. The media component level bandwidth (i.e. Maximum Requested Bandwidth for UL/DL) may be applied for all media subcomponents within a media component, since no bandwidth information is included for each flow (i.e. they are using the same bandwidth) . This works fine for P-CSCF acting as an AF, since there is no need to include more than one media subcomponent representing non-RTCP flow. Currently, in 3GPP TS29.212 and 3GPP TS29.214, the resource sharing concept is defined at media components for multiple Rx sessions. Meanwhile, currently 3GPP TS29.212 Release 14 specifies that at most 2 Flow-Description Attribute Value Pairs (AVPs) can be included in one Media-Sub-Component. For example, one example Media-Sub-Component description can be shown as follows:

Media-Sub-Component: : =<AVP Header: 519>

{Flow-Number} ; Ordinal number of the IP flow

0*2 [Flow-Description] ; UL and/or DL

[Flow-Status]

[Flow-Usage]

[Max-Requested-Bandwidth-UL]

[Max-Requested-Bandwidth-DL]

[AF-Signalling-Protocol]

[ToS-Traffic-Class]

*[AVP]

References:

1) . 3GPP TS 29.214 Release 14

2) . 3GPP TS 29.212 Release 14

3) . 3GPP TS 29.213 Release 14

Summary

As the demand increases for varying types of applications due to network capability exposure to non-3GPP domain, a third party AF (e.g. a gaming service provider) can send multiple (>2) non-RTCP flows representing services provided by different servers (these servers can be in an Active-Active mode for redundancy purpose) in one media component of an AF session. These non-RTCP flows provide connectivity in N-way active mode, and thus are expected to share bandwidth.

With existing art, PCRF will provision PCC rule (s) for those flows but the bandwidth of those flows is the sum of all individual flows’bandwidth, not a shared one, i.e. bandwidth sharing among multiple uplink and/or downlink service data flows cannot be achieved. Meanwhile, the AF cannot send all those flows in one subcomponent either because the subcomponent only supports maximum 2 flows currently.

This leads to a waste of resources in both Radio Access Network (RAN) and Core Network (CN) because the network allocates more resource than what is actually needed. Existing 3GPP technology is not flexible enough to satisfy different needs from the third party AF, in some of them more servers’media flow description of the flows must be included in one media component, therefore more resources will be reserved in the 3GPP system and not be used by the UE.

Although 3GPP provides the capability for the P-CSCF (i.e., AF) to indicate to the PCRF that media of an AF session may share resources with media belonging to other AF sessions. However this functionality does not apply to resource sharing of service data flows belonging to the same AF session.

In view of the above deficiency, an object of the embodiments herein is therefore to propose methods and servers for realizing the bandwidth sharing among multiple uplink and/or downlink service data flows.

According to an aspect, the object is achieved by a method for sharing bandwidth among multiple uplink and/or downlink service data flows, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component, the method comprising: receiving a message indicating support of bandwidth sharing; and generating at least one Policy and Charging Control (PCC) rule, the at least one PCC rule indicates bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component.

According to another aspect, the object is achieved by a method for enforcing bandwidth sharing among multiple uplink and/or downlink service data flows, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component, the method comprising: receiving at least one Policy and Charging Control (PCC) rule, the at least one PCC rule indicates bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component; and enforcing the received PCC rule.

According to yet another aspect, the object is achieved by a method for sharing bandwidth among multiple uplink and/or downlink service data flows, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component, the method comprising: sending a message indicating support of bandwidth sharing; and receiving a response message indicating bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component.

According to yet another aspect, the object is achieved by a server for sharing bandwidth among multiple uplink and/or downlink service data flows, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component, the server comprising: a receiving unit, configured to receive a message indicating support of bandwidth sharing; and a generating unit, configured to generate at least one Policy and Charging Control (PCC) rule, the at least one PCC rule indicates bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component.

According to yet another aspect, the object is achieved by a server for enforcing bandwidth sharing among multiple uplink and/or downlink service data flows, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component, the server comprising: a receiving unit, configured to receive at least one Policy and Charging Control (PCC) rule, the at least one PCC rule indicates bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component; and an enforcing unit, configured to enforce the received PCC rule.

According to yet another aspect, the object is achieved by a server for sharing bandwidth among multiple uplink and/or downlink service data flows, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component, the server comprising: a sending unit, configured to send a message indicating support of bandwidth sharing; and a receiving unit, configured to receive a response message indicating bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component.

According to yet another aspect, the object is achieved by a computer-readable medium, carrying instructions, which, when executed by a processor, cause the processor to carry out any of the methods according to the above method.

With the embodiments herein, by sharing bandwidth among multiple uplink and/or downlink service data flows, more efficient resource usage in both Radio Access Network and Core Network can be achieved.

Brief Description of the Drawings

The embodiments herein will now be further described in more detail in the following detailed description by reference to the appended drawings illustrating the embodiments and in which:

Figure 1 shows an example of bandwidth sharing among multiple uplink and/or downlink service data flows according to embodiments;

Figure 2 shows another example of bandwidth sharing among multiple uplink and/or downlink service data flows according to embodiments;

Figure 3 shows yet another example of bandwidth sharing among multiple uplink and/or downlink service data flows according to embodiments;

Figure 4 is a schematic diagram showing multiple service data flows sharing bandwidth according to embodiments;

Figure 5 is a schematic flow chart showing a method in a PCC rule generating node according to embodiments;

Figure 6 is a schematic flow chart showing a method in a PCC rule enforcing node according to embodiments;

Figure 7 is a schematic flow chart showing a method in the Application Function according to embodiments;

Figure 8 is a schematic block diagram showing a PCC rule generating node according to embodiments;

Figure 9 is a schematic block diagram showing a PCC rule enforcing node according to embodiments;

Figure 10 is a schematic block diagram showing an Application Function according to embodiments;

Figure 11 is a schematic block diagram showing an apparatus according to embodiments.

Detailed Description of Embodiments

Embodiments herein will be described in detail hereinafter with reference to the accompanying drawings, in which embodiments are shown. These embodiments herein may, however, be embodied in many different forms and should not be construed as being limited to the embodiments set forth herein. The elements of the drawings are not necessarily to scale relative to each other. Like numbers refer to like elements throughout.

Reference to "one embodiment" or "an embodiment" means that a particular feature, structure or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of the phrase "in one embodiment" appearing in various places throughout the specification are not necessarily all referring to the same embodiment.

The term "A, B, or C" used herein means "A" or "B" or "C" ; the term "A, B, and C" used herein means "A" and "B" and "C" ; the term "A, B, and/or C" used herein means "A" , "B" , "C" , "A and B" , "A and C" , "B and C" or "A, B, and C" .

Figure 1 shows an example of bandwidth sharing among multiple uplink and/or downlink service data flows according to embodiments, which shows detailed procedure of allowing more than two Flow-Description Attribute Value Pairs (AVPs) in one Media-Sub-Component. In one embodiment, the definition of Media-Sub-Component is updated in order to allow more than two Flow-Description AVPs. In this embodiment, the Media-Sub-Component can be as follows:

Media-Sub-Component: : =<AVP Header: 519>

{Flow-Number} ; Ordinal number of the IP flow

*[Flow-Description] ; UL and/or DL

[Flow-Status]

[Flow-Usage]

[Max-Requested-Bandwidth-UL]

[Max-Requested-Bandwidth-DL]

[AF-Signalling-Protocol]

[ToS-Traffic-Class]

*[AVP]

In another embodiment, a new AVP indicating additional flow description is added in Media-Sub-Component, in order to keep backwards compatibility.

In one embodiment, allowing more than two Flow-Description AVPs in one Media-Sub-Component can be achieved by the following procedure:

Step 1. During Rx session setup, the AF sends AAR (AA Request) message to the PCRF (the PCC rule generating node) . In the message, the AF indicates the support of multiple flows in media subcomponent, i.e. more than two Flow-Description AVPs in one Media-Sub-Component. The AF also includes all the Flow-Description AVPs sharing the same bandwidth in one Media-Sub-Component.

Step 2. the PCRF authorizes the service data flows and handles Media-Sub-Component which contains multiple flows sharing the same bandwidth. The PCRF will generate a PCC rule for this Media-Sub-Component. If the PCRF does not support multiple flows (more than two flows) in subcomponent, the PCRF may reject the request or may accept part of (two at maximum) Flow-Description AVPs (the behavior will depend on whether the feature is defined as mandatory or optional to be supported) .

Step 3. the PCRF sends AAA (AA Answer) message to the AF. In the message, the PCRF indicates the support of multiple flows in subcomponent. If the PCRF does not support multiple flows in subcomponent and rejects the request,

step

4 and 5 are skipped.

Step 4. the PCRF sends RAR (Re-Auth-Request) message to the PGW (the PCC rule enforcing node) to install the PCC rule generated in step 2.

Step 5. the PGW sends RAA (Re-Auth-Answer) message to the PCRF to acknowledge the PCC rule installation.

Step 6. If in step 3, the PCRF does not indicate the support of multiple flows in subcomponent, the AF may initiate another AAR for the demanded service again using legacy way and in this case the AF takes also the result in AAA into consideration.

Step 7. If step 6 is executed, the PCRF sends AAA message to the AF.

If the feature is supported, the AF will apply the same mechanism as part of the AF session modification request. That is, multiple flow descriptions could be added in any AAR message initiated within that AF session.

Here, the PCRF and the PGW are shown as example of the PCC rule generating node and the PCC rule enforcing node, respectively; but the embodiments does not limit to this case.

In the above embodiments, bandwidth sharing among flows in a media subcomponent can be achieved in a simple way. Therefore, the embodiments enable the use case where multiple uplink and/or downlink service data flows should share a common bandwidth, to ensure more efficient network resource (especially radio resource) usage.

Figure 2 shows another example of bandwidth sharing among multiple uplink and/or downlink service data flows according to embodiments, in which detailed procedure of bandwidth sharing across Media-Sub-Components by bandwidth sharing information is shown. In this example, an optional new AVP Bandwidth-Sharing-Information, which indicates whether uplink and/or downlink bandwidth provided in Media-Component-Description are shared among all Media-Sub-Components, is added in Media-Component-Description. In one embodiment, the example Media-Component-Description can be shown as follows:

Media-Component-Description: : =<AVP Header: 517>

{Media-Component-Number} ; Ordinal number of the media comp.

* [Media-Sub-Component] ; Set of flows for one flow identifier

[AF-Application-Identifier]

[Media-Type]

[Max-Requested-Bandwidth-UL]

[Max-Requested-Bandwidth-DL]

[Min-Requested-Bandwidth-UL]

[Min-Requested-Bandwidth-DL]

[Flow-Status]

[Reservation-Priority]

[RS-Bandwidth]

[RR-Bandwidth]

* [Codec-Data]

[Bandwidth-Sharing-Information]

In one embodiment, the component level bandwidth (bandwidth of the media component) is shared among all media subcomponents for uplink and/or downlink respectively.

In one embodiment, bandwidth sharing across media subcomponents by bandwidth sharing information can be achieved by the following procedure:

Step 1. During Rx session setup, the AF sends AAR message to the PCRF (the PCC rule generating node) . In the message, the AF indicates the support of bandwidth sharing and the AF also includes Bandwidth-Sharing-Information in Media-Component-Description indicating whether uplink bandwidth and/or downlink bandwidth provided in Media-Component-Description are shared among all media subcomponents.

Step 2. the PCRF authorizes the service data flows and handles the bandwidth sharing. The PCRF creates a single PCC rule which corresponds to all media subcomponents sharing the bandwidth and calculates the bandwidth based also on Bandwidth-Sharing-Information. If the PCRF doesn’t support bandwidth sharing or the Bandwidth-Sharing-Information indicates that sharing does not apply, the PCRF generates a PCC rule per media subcomponent and authorizes the accumulated bandwidth of all media subcomponents, as legacy.

Step 3. The PCRF sends AAA message to AF. In the message, the PCRF indicates the support of bandwidth sharing. If the PCRF does not indicate the support of bandwidth sharing, the AF may trigger another AAR message to change service information, e.g. reduce the bandwidth of service data flows.

Step 4. The PCRF sends RAR message to the PGW (the PCC rule enforcing node) to install the PCC rule generated in step 2.

Step 5. The PGW sends RAA message to the PCRF to acknowledge the PCC rule installation.

If the feature is supported, the same mechanism will apply for the AF session modification procedure.

In one embodiment, to enable and apply the bandwidth sharing in this example, the media subcomponent within the Media-Component-Description should follow below rules:

· there should be no Max-Requested-Bandwidth-UL or Max-Requested-Bandwidth-DL provided in any media subcomponent

· there should be no Flow-Status provided in media subcomponent.

If there should be a media subcomponent which has a separate bandwidth or flow status, another Media-Component-Description should be provided.

Note that, with EPC supporting 5G Dual Radio (5G deployment option 3) , the aforementioned Max-Requested-Bandwidth-UL/DL AVP may be represented by another AVP indicating bit rate in kbps.

In the above embodiments, bandwidth sharing across media subcomponents can be achieved in a simple way. Therefore, the embodiments enable the use case where multiple uplink and/or downlink service data flows should share a common bandwidth, to ensure more efficient network resource (especially radio resource) usage.

Figure 3 shows yet other example of bandwidth sharing among multiple uplink and/or downlink service data flows according to embodiments, in which detailed procedure of bandwidth sharing across multiple media subcomponents by sharing key is shown.

In this example, the resource sharing on the media subcomponent level is proposed. It is to introduce sharing keys for UL and/or DL at subcomponent level. In one embodiment, an example Media-Sub-Component can be shown as follows:

Media-Sub-Component: : =<AVP Header: 519>

{Flow-Number} ; Ordinal number of the IP flow

0*2 [Flow-Description] ; UL and/or DL

[Flow-Status]

[Flow-Usage]

[Max-Requested-Bandwidth-UL]

[Max-Requested-Bandwidth-DL]

[AF-Signalling-Protocol]

[ToS-Traffic-Class]

[Sharing-Key-DL]

[Sharing-Key-UL]

* [AVP]

This embodiment allows multiple media subcomponents to share the same bandwidth meanwhile each media subcomponents can keep their own flow status. Therefore, this embodiment enables the use case where multiple uplink and/or downlink service data flows should share a common bandwidth, to ensure more efficient network resource (especially radio resource) usage.

When the PCRF receives Rx session requests, the PCRF can map sharing keys for DL and/or UL at media subcomponents into ones in associated PCC rules of the Gx session, which is defined in Charging-Rule-Definition AVP, and send it to the PCEF for resource sharing handling.

In one embodiment, bandwidth sharing across multiple media subcomponents by sharing key can be achieved by the following procedure:

Step 1. The PCEF (the PCC rule enforcing node) sends Gx CCR-I message to establish a Gx session, in the message the PCEF indicates the support of subcomponent sharing key.

Step 2. The PCRF (the PCC rule generating node) returns Gx CCA message. In the message the PCRF indicates the support of subcomponent sharing key.

Step 3. The AF sends Rx AAR-I message to establish an Rx session. In the message, the AF indicates the support of subcomponent sharing key, including multiple media subcomponents with bandwidth sharing key.

Step 4. The PCRF performs Rx session authorization and returns Rx AAA-I message indicating support of subcomponent sharing key.

Step 5. The PCRF derives PCC rules with bandwidth sharing key from the received Rx session information.

Step 6. The PCRF sends Gx RAR message including PCC rules with bandwidth sharing key to the PCEF.

Step 7. The PCEF considers bandwidth sharing key and allocates corresponding bandwidth for each PCC rule.

Step 8. The PCEF returns Gx RAA message to the PCRF.

Here, the PCRF and the PCEF are shown as example of the PCC rule generating node and the PCC rule enforcing node, respectively; but the embodiments does not limit to this case.

In one embodiment, sharing keys at media subcomponent level for the same Rx sessions can coexist with sharing keys at media components for different Rx sessions. Figure 4 is a schematic diagram showing multiple data flows sharing bandwidth according to embodiments.

In one embodiment, the PCRF will send each PCC rule with sharing key(s) on media component level and/or media subcomponent level. The PCEF will enforce those rules and perform the policing control as follows:

- the maximum bandwidth in those PCC rules is used as total bandwidth for those PCC rules including the same sharing key;

- the bandwidth limitation for each PCC rule is indicated in the corresponding rule itself.

Note that, in one embodiment, a PCC rule can be associated with 2 sharing keys if both media component level and media subcomponent level indicate different sharing. In order to support it, multiple instances of Sharing-Key-DL and Sharing-Key-UL need be supported in Charging-Rule-Definition.

Charging-Rule-Definition: : =<AVP Header: 1003>

{Charging-Rule-Name}

[Service-Identifier]

[Rating-Group]

* [Flow-Information]

[Default-Bearer-Indication]

[TDF-Application-Identifier]

[Flow-Status]

[QoS-Information]

[PS-to-CS-Session-Continuity]

[Reporting-Level]

[Online]

[Offline]

[Metering-Method]

[Precedence]

[AF-Charging-Identifier]

* [Flows]

[Monitoring-Key]

[Redirect-Information]

[Mute-Notification]

[AF-Signalling-Protocol]

[Sponsor-Identity]

[Application-Service-Provider-Identity]

* [Required-Access-Info]

* [Sharing-Key-DL]

* [Sharing-Key-UL]

[Traffic-Steering-Policy-Identifier-DL]

[Traffic-Steering-Policy-Identifier-UL]

[Content-Version]

* [AVP]

The following example shows how sharing keys at media subcomponent level and sharing keys at media components level for the same Rx sessions can work together. Therefore, the network resource usage can be further improved.

In one embodiments, there two Rx sessions: RX1 and RX2, for example. In RX1 session, there is one media component RX1_MC1 which consists of three media subcomponents: RX1_MC1_SMC1 (10M) , RX1_MC1_SMC2 (5M) , RX1_MC1_SMC3 (20M) . They have bandwidth sharing key: ShareKey_1. At media component level, it has bandwidth sharing key: SharingKey_2. In RX2 session, there is one media component RX2_MC1, which consists of three media subcomponents: RX2_MC1_SMC1 (8M) , RX2_MC1_SMC2 (5M) , RX2_MC1_SMC3 (10M) . They have bandwidth sharing key: ShareKey_3. At media component level, it has bandwidth sharing key: SharingKey_2.

RX1_MC1

{RX1_MC1_SMC1: SharingKey_1; Max_Required_Bandwidth (10M)

RX1_MC1_SMC2: SharingKey_1; Max_Required_Bandwidth (5M)

RX1_MC1_SMC3: SharingKey_1: Max_Required_Bandwidth (20M)

SharingKey_2

}

RX2_MC1

{RX2_MC1_SMC1: SharingKey_3; Max_Required_Bandwidth (8M)

RX2_MC1_SMC2: SharingKey_3; Max_Required_Bandwidth (5M)

RX2_MC1_SMC3: SharingKey_3: Max_Required_Bandwidth (10M)

SharingKey_2

}

In RX1_MC1, media component RX1_MC1_SMC3 shares the bandwidth (20M) with RX1_MC1_SMC1 (10M) and RX1_MC1_SMC2 (5M) .

RX2_MC1shares the same bandwidth (20M) with RX1_MC1. At the same time, RX2_MC1_SMC3 shares the bandwidth (10M) with RX2_MC1_SMC1 (8M) and RX2_MC1_SMC2 (5M) .

The PCRF provides the following PCC rules to the PCEF, and then the PCEF allocates corresponding bandwidth for each PCC rule in a dedicated bearer.

PCC rule 1 with (Maximum bandwidth 5M, SharingKey1, SharingKey2) for RX1_MC1_SMC1

PCC rule 2 with (Maximum bandwidth 10M, SharingKey1, SharingKey2) for RX1_MC1_SMC2

PCC rule 3 with (Maximum bandwidth 20M, SharingKey1, SharingKey2) for RX1_MC1_MSC3

PCC rule 4 with (Maximum bandwidth 5M, SharingKey3, SharingKey2) for RX2_MC1_MSC1

PCC rule 5 with (Maximum bandwidth 8M, SharingKey3, SharingKey2) for RX2_MC1_MSC2

PCC rule 6 with (Maximum bandwidth 10M, SharingKey3, SharingKey2) for RX2_MC1_MSC3

The resulted bandwidth allocation can be seen from Figure 4. Note that, in the example, sharing key and maximum bandwidth are not described for uplink and/or downlink separately, for simplicity.

As seen above, the embodiments make the following changes on 3GPP Technical Specification.

For embodiment of allowing more than two Flow-Description AVPs in one Media-Sub-Component:

· For Rx interface (between AF and PCRF) : new feature bit for “Multiple Flows in Subcomponent” should be added to Supported-Features AVP. In addition, multiple instances of Flow-Description AVP should be allowed.

For embodiment of bandwidth sharing across Media-Sub-Components by Bandwidth-Sharing-Information:

· For Rx interface (between AF and PCRF) : new feature bit for “Bandwidth Sharing” should be added to Supported-Features AVP; new AVP “Bandwidth-Sharing-Information” should be added in Media-Component-Description.

For embodiment of bandwidth sharing across Multiple Media Subcomponents by Bandwidth Sharing Key:

· For Rx interface Sharing-Key-UL and Sharing-Key-DL are added in Media-Sub-Component.

· The use of Max-Supported-Bandwidth-UL/DL should be allowed at sub-media-component level in TS 29.213.

· For Gx interface multiple instances of Sharing-Key-UL and Sharing-Key-DL are supported in Charging-Rule-Definition AVP.

Note that, in one embodiment, in 5G CN (Chinese 5G standard) , the above-mentioned solutions will also be applicable with differences as bellow:

PCF (Policy Control Function) replaces PCRF, and SMF (Session Management Function) and UPF (User Plane Function) replace PCEF;

Relevant messages and AVPs are replaced by corresponding messages and information elements defined in 5G. Note that, 5G also supports Rx interface to allow interoperability with existing applications. In that sense, the embodiments are also compliant with 5G networks.

Figure 5 is a schematic flow chart showing a method 500 in the PCC rule generating node (for example, the above mentioned PCRF) according to embodiments. The method 500 may be performed by the PCC rule generating node, in order to share bandwidth among multiple uplink and/or downlink service data flows. The service data flows are included in at least one media subcomponent, and the at least one media subcomponent is further included in at least one media component.

The method 500 may begin with step S501, the PCC rule generating node may receive a message indicating support of bandwidth sharing of multiple uplink and/or downlink service data flows.

In one embodiment, referring to the description of Figure 1, the message may include bandwidth sharing information, which indicates more than two flow description information elements in one media subcomponent description, in order to allow more than two flows to share a bandwidth in a media subcomponent. Although the example in Figure 1 shows Flow Description AVPs as example of flow description information elements, the embodiments can also be applicable to these used for XML-based Rx.

In one embodiment, referring to the description of Figure 2, the message may indicate bandwidth sharing information in media component description, indicating whether uplink bandwidth and/or downlink bandwidth provided in media component description is shared among all media subcomponents, in order to allow the bandwidth to be shared across media subcomponents.

In one embodiment, referring to the description of Figure 3, the message may indicate the support of subcomponent sharing key, in order to allow bandwidth to be shared among media subcomponents within a media component.

In one embodiment, referring to the description of Figure 4, the message may also indicate sharing key at media component level in addition to subcomponent sharing key, in order to allow bandwidth to be shared among both media component level and media subcomponent level. That is, the bandwidth can be shared among service data flows of same media components and different media components.

Then, the method 500 proceeds to step S502, the PCC rule generating node may generate at least one Policy and Charging Control (PCC) rule. The at least one PCC rule indicates bandwidth sharing at least among multiple uplink and/or downlink service data flows within the same media component. Here, "flows within the same media component" may refer to flows within the same media subcomponent of the same media component and flows within different media subcomponents but within the same media component.

In one embodiment, referring to the description of Figure 1, a single PCC rule is generated for media subcomponent which contains more than two flows, and the more than two flows share a bandwidth in the same media subcomponent.

In one embodiment, referring to the description of Figure 2, a single PCC rule is generated and the PCC rule corresponds to all media subcomponents sharing the bandwidth, and the bandwidth is calculated based on the bandwidth sharing information.

In one embodiment, referring to the description of Figure 3, a plurality of PCC rules are generated, and each PCC rule has at least one bandwidth sharing key corresponding to the received subcomponent sharing key.

In one embodiment, referring to the description of Figure 4, each PCC rule may also indicate sharing key at media component level, to allow bandwidth to be shared among media components.

In one embodiment, the method 500 can be implemented by PCRF or can be implemented by PCF in 5G. In one embodiment, the message in Step S501 is received from AF, PCEF, or SMF.

In one embodiment, the method 500 further comprising Step S503, the PCC rule generating node may send the generated at least one PCC rule to PGW, PCEF, or SMF to enforce it.

The above steps are only examples, and the PCC rule generating node can perform any actions described in connection to Figures 1-3, to share bandwidth among multiple uplink and/or downlink service data flows.

Figure 6 is a schematic flow chart showing a method 600 in the PCC rule enforcing node according to embodiments. The method is performed for example by PCEF or PGW, for enforcing bandwidth sharing among multiple uplink and/or downlink service data flows.

In one embodiment, the method 600 may begin with step S601, the PCC rule enforcing node may receive at least one PCC rule, the at least one PCC rule may indicate bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component. In one embodiment, the received PCC rule may be the PCC rule generated in step S502 of the method 500.

In one embodiment, the method may proceed to step S602, the PCC rule enforcing node may enforce the received PCC rule. In one embodiment, the enforcement of the received PCC rule further comprising allocating corresponding bandwidth according to each PCC rule.

In one embodiment, the method 600 can be implemented by PCEF, SMF or PGW, and the at least one PCC rule is received from PCRF or PCF.

The above steps are only examples, and the PCC rule enforcing node can perform any actions described in connection to Figures 1-3, to share bandwidth among multiple uplink and/or downlink service data flows.

Figure 7 is a schematic flow chart showing a method 700 in the Application Function (AF) according to embodiments. The method 700 can be performed by Application Function, for sharing bandwidth among multiple uplink and/or downlink service data flows.

The method 700 may begin with step S701, the AF may send a message (for example, an indication message) indicating support of bandwidth sharing. In one embodiment, the sent indication message can be the same message as in step S501 of method 500. In one embodiment, the method may proceed to step S702, the AF may receive a response message indicating bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component. Here, "flows within the same media component" may refer to flows within the same media subcomponent of the same media component and flows within different media subcomponents but within the same media component.

The above steps are only examples, and the AF can perform any actions described in connection to Figures 1-3, to share bandwidth among multiple uplink and/or downlink service data flows.

In the above embodiments shown in Figure 5-7, bandwidth sharing of multiple uplink and/or downlink service data flows in the same media subcomponent and/or the same media component can be achieved, and thus the network resource (especially radio resource) can be used in a more efficient way.

Figure 8 is a schematic block diagram showing a PCC rule generating node 800 according to embodiments. The PCC rule generating node may be implemented in a network function (network server) , such as PCRF or PCF, for sharing bandwidth among multiple uplink and/or downlink service data flows. In one embodiment, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component. In one embodiment, the PCC rule generating node may comprise a receiving unit 801, a generating unit 802, and a sending unit 803.

In one embodiment, the receiving unit 801 may be configured to perform the step S501 in method 500. In one embodiment, the generating unit 802 may be configured to perform the step S502 in method 500. In one embodiment, the sending unit 803 may be configured to perform the step S503 in method 500. The detailed descriptions related to the receiving unit 801, the generating unit 802, and the sending unit 803 are omitted herein for simplicity.

Note that, the PCC rule generating node 800 can be performed as hardware, software, firmware and any combination thereof. For example, the PCC rule generating node 800 may include a plurality of units, circuities, modules or the like, each of which can be used to perform one or more step of the example method 500 or one or more step shown in Figure 1-3 related to the PCC rule generating node.

As an example, in the PCC rule generating node 800, a first module is configured to perform the step S501 in method 500, a second module is configured to perform the step S502 in method 500, and a third module is configured to perform the step S503 in method 500.

Figure 9 is a schematic block diagram showing a PCC rule enforcing node 900 according to embodiments. The PCC rule enforcing node 900 may be implemented in a network function (network server) , such as PGW shown in Figure 1 and 2 or PCEF shown in Figure 3, for enforcing bandwidth sharing among multiple uplink and/or downlink service data flows. In one embodiment, the PCC rule enforcing node 900 may comprise a receiving unit 901 and an enforcing unit 902.

In one embodiment, the receiving unit 901 may be configured to perform the step S601 in method 600. In one embodiment, the enforcing unit 902 may be configured to perform the step S602 in method 600. In one embodiment, the enforcing unit 902 may include an allocating unit (not shown in Figure 9) , which is configured to allocate corresponding bandwidth for each PCC rule. The detailed descriptions related to the receiving unit 901, and the enforcing unit 902 are omitted herein for simplicity.

Note that, the PCC rule enforcing node 900 can be performed as hardware, software, firmware and any combination thereof. For example, the PCC rule enforcing node 900 may include a plurality of units, circuities, modules or the like, each of which can be used to perform one or more step of the example method 600 or one or more step shown in Figure 1-3 related to the PCC rule enforcing node.

As an example, in the PCC rule enforcing node 900, a first module is configured to perform the step S601 in method 600, and a second module is configured to perform the step S602 in method 600.

Figure 10 is a schematic block diagram showing an Application Function (AF) 1000 according to embodiments. The AF 1000 may be implemented as a server for sharing bandwidth among multiple uplink and/or downlink service data flows. In one embodiment, the Application Function 1000 may comprise a sending unit 1001 and a receiving unit 1002.

In one embodiment, the sending unit 1001 may be configured to perform the step S701 in method 700. In one embodiment, the receiving unit 1002 may be configured to perform the step S702 in method 700. The detailed descriptions related to the sending unit 1001, and the receiving unit 1002 are omitted herein for simplicity.

Note that, the Application Function 1000 can be performed as hardware, software, firmware and any combination thereof. For example, the Application Function 1000 may include a plurality of units, circuities, modules or the like, each of which can be used to perform one or more step ofthe example method 700 or one or more step shown in Figure 1-3 related to the AF.

As an example, in the AF 1000, a first module is configured to perform the step S701 in method 700, and a second module is configured to perform the step S702 in method 700.

Figure 11 is a schematic block diagram showing an apparatus 1100 according to embodiments. In one embodiment, the apparatus 1100 can be configured as any of the above mentioned server or function, such as PGW, PCRF, PCF, AF, PCEF, SMF, UDF.

In one embodiment, the apparatus 1100 may include but not limited to a Central Processing Unit (CPU) 1101, a computer-readable medium 1102, and a memory 1103.

The memory 1103 may comprise a volatile (e.g. RAM) and/or non-volatile memory (e.g. a hard disk or flash memory) . In one embodiment, the computer-readable medium 1102 may be configured to store a computer program and/or instructions, which, when executed by the processor 1101, causes the processor 1101 to carry out any of the above mentioned methods. In another embodiment, the computer program can be stored in a remote location for example computer program product 1104, and accessible by the processor 1101 via for example carrier 1105.

The computer program product 1104 can be distributed and/or stored on a removable computer-readable medium, e.g. diskette, CD (Compact Disk) , DVD (Digital Video Disk) , flash or similar removable memory media (e.g. compact flash, SD secure digital, memory stick, mini SD card, MMC multimedia card, smart media) , HD-DVD (High Definition DVD) , or Blu-ray DVD, USB (Universal Serial Bus) based removable memory media, magnetic tape media, optical storage media, magneto-optical media, bubble memory, or distributed as a propagated signal via a network (e.g. Ethernet, ATM, ISDN, PSTN, X. 25, Internet, Local Area Network (LAN) , or similar networks capable of transporting data packets to the infrastructure node) .

While the embodiments have been illustrated and described herein, it will be understood by those skilled in the art that various changes and modifications may be made, and equivalents may be substituted for elements thereof without departing from the true scope of the present technology. In addition, many modifications may be made to adapt to a particular situation and teaching herein without departing from its central scope. Therefore it is intended that the present embodiments should not be limited to the particular embodiments disclosed as the best mode contemplated for carrying out the present technology, but that the present embodiments include all embodiments falling within the scope of the appended claims.

Abbreviations

3GPP third Generation Partnership Project

5G 5th generation of radio NW

AF Application Function

AVP Attribute Value Pairs

CN Core Network

GGSN Gateway GPRS Support Node

GPRS General Packet Radio Service

IM Internet protocol Multimedia

PCC Policy and Charging Control

PCEF Policy and Charging Enforcement Function

PCF Policy Control Function

PCRF Policy and Charging Rules Function

P-CSCF Proxy Call Session Control Function

PDN Packet Data Network

PDG Packet Data Gateway

RTCP Real-Time Control Protocol

RAN Radio Access Network

SDF Service Data Flow

SMF Session Management Function

UPF User Plane Function

WLAN Wireless Local Access Network

Claims

A method for sharing bandwidth among multiple uplink and/or downlink service data flows, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component, the method comprising:

- receiving a message indicating support of bandwidth sharing; and

- generating at least one Policy and Charging Control (PCC) rule, the at least one PCC rule indicates bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component.
The method according to claim 1, wherein the message indicates more than two flow description information elements in a media subcomponent description, to allow the bandwidth to be shared among more than two flows within the media subcomponent.
The method according to claim 1, wherein the message includes bandwidth sharing information in a media component description, indicating whether uplink bandwidth and/or downlink bandwidth provided in the media component description is shared among more than one media subcomponent, to allow the bandwidth to be shared across media subcomponents within the media component.
The method according to claim 3, wherein a single PCC rule is generated and the PCC rule corresponds to all media subcomponents sharing the bandwidth, and the bandwidth is calculated based on the bandwidth sharing information.
The method according to claim 1, wherein the message indicates the support of subcomponent sharing key, to allow bandwidth to be shared among media subcomponents within the media component.
The method according to claim 5, wherein a plurality of PCC rules are generated, and each PCC rule has at least one bandwidth sharing key corresponding to the subcomponent sharing key.
The method according to claim 5, wherein the message also indicates sharing key among a plurality of media components, to allow bandwidth to be shared among flows within different media components.
The method according to any one of claims 1-7, wherein the method is implemented by Policy and Charging Rule Function (PCRF) or Policy Control Function (PCF) , and the message is received from Application Function (AF) , Packet data network GateWay (PGW) , Policy Control and Enforcement Function (PCEF) , or Session Management Function (SMF) .
The method according to any one of claims 1-8, wherein the method further comprising:

- sending the generated at least one PCC rule to Policy Control and Enforcement Function (PCEF) , Session Management Function (SMF) , or Packet data network GateWay (PGW) to enforce the generated at least one PCC rule.
A method for enforcing bandwidth sharing among multiple uplink and/or downlink service data flows, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component, the method comprising:

- receiving at least one Policy and Charging Control (PCC) rule, the at least one PCC rule indicates bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component; and

- enforcing the received PCC rule.
The method according to claim 10, wherein a single PCC is generated for a media subcomponent which contains more than two flows, and the bandwidth is shared among the more than two flows within the media subcomponent.
The method according to claim 10, wherein a single PCC rule is received and the PCC rule corresponds to all media subcomponents sharing the bandwidth, and the bandwidth is calculated based on the bandwidth sharing information.
The method according to claim 10, wherein a plurality of PCC rules are received, and each PCC rule has at least one bandwidth sharing key corresponding to a subcomponent sharing key, to allow bandwidth to be shared among media subcomponents within the media component.
The method according to claim 13, wherein each PCC rule also indicates sharing key among a plurality of media components, to allow bandwidth to be shared among flows within different media components.
The method according to any one of claims 10-14, wherein the method is implemented by Policy Control and Enforcement Function (PCEF) , Session Management Function (SMF) or Packet data network GateWay (PGW) , and the at least one PCC rule is received from Policy and Charging Rule Function (PCRF) or Policy Control Function (PCF) .
The method according to any one of claims 10-15, wherein enforcing the received PCC rule further comprising:

- allocating corresponding bandwidth according to each PCC rule.
A method for sharing bandwidth among multiple uplink and/or downlink service data flows, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component, the method comprising:

- sending an indication message indicating support of bandwidth sharing; and

- receiving a response message indicating bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component.
The method according to claim 17, wherein the indication message indicates more than two flow description information elements in a media subcomponent description, to allow the bandwidth to be shared among more than two flows within the media subcomponent.
The method according to claim 17, wherein the indication message includes bandwidth sharing information in a media component description, indicating whether uplink bandwidth and/or downlink bandwidth provided in the media component description is shared among more than one media subcomponent, to allow the bandwidth to be shared across media subcomponents within the media component.
The method according to claim 17, wherein the indication message indicates the support of subcomponent sharing key, to allow bandwidth to be shared among media subcomponents within the media component.
The method according to claim 20, wherein the indication message also indicates sharing key among a plurality of media components, to allow bandwidth to be shared among flows within different media components.
The method according to any one of claims 17-21, wherein the method is implemented by Application Function (AF) , and the response message is received from Policy and Charging Rule Function (PCRF) or Policy Control Function (PCF) .
An apparatus for sharing bandwidth among multiple uplink and/or downlink service data flows, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component, the apparatus comprising:

- a first module, configured to receive a message indicating support of bandwidth sharing; and

- a second module, configured to generate at least one Policy and Charging Control (PCC) rule, the at least one PCC rule indicates bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component.
The apparatus according to claim 23, wherein the message indicates more than two flow description information elements in a media subcomponent description, to allow the bandwidth to be shared among more than two flows within the media subcomponent.
The apparatus according to claim 23, wherein the message includes bandwidth sharing information in a media component description, indicating whether uplink bandwidth and/or downlink bandwidth provided in the media component description is shared among more than one media subcomponent, to allow the bandwidth to be shared across media subcomponents within the media component.
The apparatus according to claim 25, wherein a single PCC rule is generated and the PCC rule corresponds to all media subcomponents sharing the bandwidth, and the bandwidth is calculated based on the bandwidth sharing information.
The apparatus according to claim 23, wherein the message indicates the support of subcomponent sharing key, to allow bandwidth to be shared among media subcomponents within the media component.
The apparatus according to claim 27, wherein a plurality of PCC rules are generated, and each PCC rule has at least one bandwidth sharing key corresponding to the subcomponent sharing key.
The apparatus according to claim 27, wherein the message also indicates sharing key among a plurality of media component, to allow bandwidth to be shared among flows with different media components.
The apparatus according to any one of claims 23-29, wherein the apparatus acts as Policy and Charging Rule Function (PCRF) or Policy Control Function (PCF) , and the message is received from Application Function (AF) , Packet data network GateWay (PGW) , Policy Control and Enforcement Function (PCEF) , or Session Management Function (SMF) .
The apparatus according to any one of claims 23-30, wherein the apparatus further comprising:

- a third module, configured to send the generated at least one PCC rule to Policy Control and Enforcement Function (PCEF) , Session Management Function (SMF) , or Packet data network GateWay (PGW) to enforce the generated at least one PCC rule.
An apparatus for enforcing bandwidth sharing among multiple uplink and/or downlink service data flows, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component, the apparatus comprising:

- a first module, configured to receive at least one Policy and Charging Control (PCC) rule, the at least one PCC rule indicates bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component; and

- a second module, configured to enforce the received PCC rule.
The apparatus according to claim 32, wherein a single PCC rule is generated for a media subcomponent which contains more than two flows, and the bandwidth is shared among the more than two flows within the media subcomponent.
The apparatus according to claim 32, wherein a single PCC rule is received and the PCC rule corresponds to all media subcomponents sharing the bandwidth, and the bandwidth is calculated based on the bandwidth sharing information.
The apparatus according to claim 32, wherein a plurality of PCC rules are received, and each PCC rule has at least one bandwidth sharing key corresponding to a subcomponent sharing key, to allow bandwidth to be shared among media sub components within the media component.
The apparatus according to claim 35, wherein each PCC rule also indicates sharing key among a plurality of media components, to allow bandwidth to be shared among flows within different media components.
The apparatus according to any one of claims 32-36, wherein the apparatus acts as Policy Control and Enforcement Function (PCEF) , Session Management Function (SMF) or Packet data network GateWay (PGW) , and the at least one PCC rule is received from Policy and Charging Rule Function (PCRF) or Policy Control Function (PCF) .
The apparatus according to any one of claims 32-37, wherein the second module further comprising:

- a third module, configured to allocate corresponding bandwidth according to each PCC rule.
An apparatus for sharing bandwidth among multiple uplink and/or downlink service data flows, the service data flows are included in at least one media subcomponent and the at least one media subcomponent is further included in at least one media component, the apparatus comprising:

- a first module, configured to send an indication message indicating support of bandwidth sharing; and

- a second module, configured to receive a response message indicating bandwidth sharing at least among multiple uplink and/or downlink service data flows within a media component.
The apparatus according to claim 39, wherein the indication message indicates more than two flow description information elements in a media subcomponent description, to allow the bandwidth to be shared among more than two flows within the media subcomponent.
The apparatus according to claim 39, wherein the indication message includes bandwidth sharing information in a media component description, indicating whether uplink bandwidth and/or downlink bandwidth provided in the media component description is shared among more than one media subcomponent, to allow the bandwidth to be shared across media subcomponents within the media component.
The apparatus according to claim 39, wherein the indication message indicates the support of subcomponent sharing key, to allow bandwidth to be shared among media subcomponents within the media component.
The apparatus according to claim 42, wherein the indication message also indicates sharing key among a plurality of media components, to allow bandwidth to be shared among flows within different media components.
The apparatus according to any one of claims 39-43, wherein the apparatus acts as Application Function (AF) , and the response message is received from Policy and Charging Rule Function (PCRF) or Policy Control Function (PCF) .
A computer-readable medium, carrying instructions, which, when executed by a processor, cause the processor to carry out any one of the methods according to claims 1-22.