CN106465194B - Method and apparatus for controlling QOS of service - Google Patents

Method and apparatus for controlling QOS of service Download PDF

Info

Publication number
CN106465194B
CN106465194B CN201480079810.9A CN201480079810A CN106465194B CN 106465194 B CN106465194 B CN 106465194B CN 201480079810 A CN201480079810 A CN 201480079810A CN 106465194 B CN106465194 B CN 106465194B
Authority
CN
China
Prior art keywords
qos
traffic
phase
service
traffic phase
Prior art date
Legal status (The legal status 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 status listed.)
Active
Application number
CN201480079810.9A
Other languages
Chinese (zh)
Other versions
CN106465194A (en
Inventor
李铮铮
李海朝
吴秀峰
罗龙
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Huawei Technologies Co Ltd
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
Publication of CN106465194A publication Critical patent/CN106465194A/en
Application granted granted Critical
Publication of CN106465194B publication Critical patent/CN106465194B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W28/00Network traffic management; Network resource management
    • H04W28/16Central resource management; Negotiation of resources or communication parameters, e.g. negotiating bandwidth or QoS [Quality of Service]
    • H04W28/24Negotiating SLA [Service Level Agreement]; Negotiating QoS [Quality of Service]

Landscapes

  • Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Embodiments of the present application provide a method and apparatus for controlling QoS of traffic. The traffic comprises GBR traffic having a first traffic phase and a second traffic phase. The method comprises the following steps: acquiring the service type of the service; acquiring a first QoS requirement aiming at the first service phase and a second QoS requirement aiming at the second service phase; and generating indication information indicating the first QoS requirements for the first traffic phase, the second QoS requirements for the second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase. The indication is used to identify the traffic phase and generate a QoS policy to control QoS in the first traffic phase and to control QoS in the second traffic phase. According to the application, resources can be efficiently allocated while user experience is guaranteed.

Description

Method and apparatus for controlling QOS of service
Technical Field
The present application relates to the field of communications technologies, and in particular, to a method and apparatus for controlling quality of service (QoS) of a service.
Background
An Evolved Packet System (EPS) refers to a telecommunication system that is designed for an architecture of a Long Term Evolution (LTE) network. The EPS bearer is an Internet Protocol (IP) flow that satisfies a certain quality of service (QoS) in the EPS, and includes a Guaranteed Bit Rate (GBR) type bearer and a non-GBR type bearer. Allocating specific resources to GBR-type bearers enables the bandwidth of the GBR-type bearers to be guaranteed even when the network load is heavy or any congestion occurs in the system. non-GBR type bearers are best effort bearers and their bandwidth is not guaranteed. The GBR bearer is mainly used for real-time traffic such as voice over Internet protocol (VoIP) traffic or online video or real-time gaming, and the non-GBR bearer is mainly used for non-real-time traffic such as e-mail, File Transfer Protocol (FTP) traffic or hypertext transfer protocol (HTTP) traffic. GBR traffic has a higher priority than non-GBR traffic.
GBR and Maximum Bit Rate (MBR) are two QoS parameters for GBR traffic. GBR indicates that the bandwidth (also referred to as bit rate) is guaranteed by the LTE network, and MBR indicates the maximum bit rate allowed in the LTE network. The bit rate of the data flow is controlled above GBR but below MBR to meet QoS requirements that affect the scheduling policy, queue management, rate shaping policy and Radio Link Control (RLC) configuration of all end-to-end network nodes in the EPS.
However, QoS parameters such as GBR or MBR are set when a GBR type bearer is established for GBR traffic. Therefore, either the resource allocation is inefficient or the user experience cannot be guaranteed.
Disclosure of Invention
The embodiment of the invention provides a method and equipment for controlling QoS of a service.
According to a first aspect, a method for controlling QoS of traffic is provided. The traffic comprises GBR traffic having at least a first traffic phase and a second traffic phase. The method performed by the first device comprises: the first device obtains the service type of the service. The first device obtains a first QoS requirement aiming at a first service stage and a second QoS requirement aiming at a second service stage according to the service type of the service. The first device generates first indication information indicating a first QoS requirement for the first traffic phase, a second QoS requirement for the second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase. The first indication information is used to generate QoS policies for controlling QoS in accordance with first QoS requirements indicated in the QoS policies in a first traffic phase and for controlling QoS in accordance with second QoS requirements indicated in the QoS policies in a second traffic phase.
In a first possible implementation form of the method according to the first aspect, the traffic phase flag is expressed in the form of any one or any combination of a time of a data packet and a packet capacity of the data packet.
In a second possible implementation form of the method according to the first aspect as such or according to the first implementation form of the first aspect, the first indication information indicates a first QoS requirement for the first traffic phase and a second QoS requirement for the second traffic phase, the QoS requirements corresponding to a first level of user experience of the traffic, the first indication information indicates further a third QoS requirement for the first traffic phase and a fourth QoS requirement for the second traffic phase, the QoS requirements corresponding to a second level of user experience of the traffic.
According to a second aspect, an apparatus for controlling QoS of traffic is provided. The traffic comprises GBR traffic having at least a first traffic phase and a second traffic phase. The apparatus includes a first acquisition unit, a second acquisition unit, and a generation unit. The first obtaining unit is used for obtaining the service type of the service. The second obtaining unit is used for obtaining a first QoS requirement aiming at the first service stage and a second QoS requirement aiming at the second service stage according to the service type of the service. The generation unit is configured to generate first indication information indicating a first QoS requirement for a first traffic phase, a second QoS requirement for a second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase. The first indication information is used to generate QoS policies for controlling QoS in accordance with first QoS requirements indicated in the QoS policies in a first traffic phase and for controlling QoS in accordance with second QoS requirements indicated in the QoS policies in a second traffic phase.
In a first possible implementation form of the apparatus according to the second aspect, the traffic phase flag is represented in the form of any one or any combination of a time of a data packet and a packet capacity of the data packet.
In a second possible implementation form of the apparatus according to the second aspect as such or according to the first implementation form of the second aspect, the first indication information indicates a first QoS requirement for the first traffic phase and a second QoS requirement for the second traffic phase, the QoS requirements corresponding to a first level of user experience of the traffic, the first indication information further indicates a third QoS requirement for the first traffic phase and a fourth QoS requirement for the second traffic phase, the QoS requirements corresponding to a second level of user experience of the traffic.
These and other aspects of the invention are apparent from and will be elucidated with reference to the embodiments described hereinafter. According to an embodiment of the application, the first device generates first indication information indicating different QoS requirements for different traffic phases and traffic phase flags identifying the different traffic phases. Based on the first indication, a first traffic phase and a second traffic phase are identified, and a QoS policy is generated to control QoS according to the first QoS requirement in the first traffic phase and according to the second QoS requirement in the second traffic phase. After receiving the QoS policies, each node in the EPS operates traffic according to the first QoS requirements in a first traffic phase and operates traffic according to the second QoS requirements in a second traffic phase. Thus, different QoS requirements for different traffic phases of the traffic are met. Accordingly, resources can be efficiently allocated while guaranteeing user experience.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments will be briefly introduced below. It is obvious that the drawings in the following description are only some embodiments of the invention, and that for a person skilled in the art, other drawings can be derived from them without inventive effort.
Fig. 1A shows a diagram of a method for establishing an EPS bearer;
figure 1B shows a diagram of a method for modifying QoS parameters of an EPS bearer;
fig. 2A shows a diagram of a method for controlling QoS of traffic according to one embodiment of the present invention;
fig. 2B illustrates a method for controlling QoS of a service when a service identification module is integrated on a first device according to one embodiment of the present invention;
fig. 2C illustrates a method for controlling QoS of a service when a service identification module is integrated on another first device according to one embodiment of the present invention;
fig. 3A and 3B, and fig. 3C and 3D respectively show four examples of a method for controlling QoS of traffic according to an embodiment of the present invention;
fig. 4A, 4B and 4C respectively show three examples of a method for controlling QoS of traffic according to an embodiment of the present invention;
fig. 5 shows a simplified block diagram of an apparatus for controlling QoS of traffic according to an embodiment of the present invention;
fig. 6A, 6B and 6C respectively show three examples of an apparatus for controlling QoS of traffic according to an embodiment of the present invention; and
fig. 7A and 7B respectively show simplified block diagrams of a second apparatus for controlling QoS of traffic according to an embodiment of the present invention.
Detailed Description
The technical solution in the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention. It is to be understood that the described embodiments are merely exemplary of the invention, and not restrictive of the full scope of the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Fig. 1A shows a diagram of a method for establishing an EPS bearer, and fig. 1B shows a diagram of a conventional method for updating EPS bearer parameters. In the example shown in fig. 1A and 1B, the EPS 100 includes a User Equipment (UE) 101, an eNodeB 102 (hereinafter referred to as "eNB"), a Mobility Management Entity (MME)103, a Serving Gateway (SGW) 104, a packet data network gateway (PGW) 105, and a Policy and Charging Rules Function (PCRF) 106. The QoS policy generated by PCRF 106 is sent to each other node in EPS 100, e.g., UE 101, eNB 102, MME 103, SGW 104 or PGW105, using the methods described below in fig. 1A and 1B.
PCRF 106 is configured to dynamically generate QoS policies and send QoS policies indicating QoS requirements for traffic to PGW 105. The PGW105 is used to enforce QoS policies. After forwarding the QoS policy through the SGW 104 and MME 103, the eNB 102 establishes a bearer with the UE 101 according to the QoS parameters.
For example, as shown in fig. 1A, a method for establishing an EPS bearer requested by a network side includes:
in step 1: by initiating an IP connectivity access network (IP-CAN) session modification procedure, PCRF 106 dynamically generates QoS policies and sends the QoS policies indicating the QoS requirements of the traffic to PGW 105.
In step 2: the PGW105 uses this QoS policy to assign a value to the QoS parameter of the EPS bearer and sends a create bearer request indicating the QoS parameter to the SGW 104.
In step 3: SGW 104 forwards the create bearer request to MME 103.
In step 4: MME 103 signals a bearer setup request message or session management request to eNB 102 indicating QoS parameters of the EPS bearer.
In steps 5 and 6, the eNB 102 maps the QoS parameters of the EPS bearer to the QoS parameters of the radio bearer. It then signals an RRC connection reconfiguration message to the UE 101. The UE 101 acknowledges the radio bearer activation to the eNB 102 with an RRC connection reconfiguration complete message.
In steps 7 to 12, the bearer activation is confirmed by direct transfer, session management response, bearer setup response, create bearer response and IP-can session modification.
As shown in fig. 1B, the method for updating EPS bearer parameters requested by the network side includes:
in step 1': by starting the IP-CAN session modification procedure, PCRF 106 dynamically generates QoS policies and sends QoS policies indicating the QoS requirements of the traffic to PGW 105;
in step 2': the PGW105 allocates a value to the QoS parameter of the EPS bearer using the QoS policy, and sends an update bearer request indicating the QoS parameter to the SGW 104;
in step 3': SGW 104 forwards the update bearer request to MME 103;
in step 4': MME 103 sends a session management request or bearer modification request message to eNB 102 indicating QoS parameters of the EPS bearer;
in steps 5 'and 6', the eNB 102 maps the QoS parameters of the EPS bearer to the QoS parameters of the radio bearer. It then signals an RRC connection reconfiguration message to the UE 101. The UE 101 confirms radio bearer activation to the eNB 102 using the RRC connection reconfiguration complete message;
in steps 7 'to 12', the bearer modification is confirmed by direct transfer, session management response, bearer modification response, update bearer response and IP-can session modification.
In the conventional method, the QoS parameter is set when the EPS bearer is established as shown in fig. 1A or when the EPS bearer parameter is modified as shown in fig. 1B, and is kept constant throughout the entire service. According to an embodiment of the present application, a method for controlling QoS of traffic is disclosed such that each node in an EPS operates according to different QoS requirements in different traffic phases.
Fig. 2A shows a flow diagram of a method for controlling QoS of traffic according to one embodiment of the present invention. The method is applicable to EPS 200, which includes UE201, eNB202, MME203, SGW204, PGW 205 and PCRF 206.
The EPS 200 further comprises a service identification module 207. The device implementing the functionality of the service identification module 207 is the first device. In one embodiment, the traffic identification module 207 is a functional module that may be integrated as a first device on any node in the EPS 200, e.g., UE201, eNB202, MME203, SGW204, PGW 205, or PCRF 206. In another embodiment, the service identification module 207 may be implemented as a first device, e.g., a controller, on a separate hardware device.
The method for controlling QoS of traffic in the EPS 200 includes:
s210: the first device obtains the service type of the service.
The service type may include, but is not limited to, VoIP service or online video service, etc.
In one embodiment, the traffic comprises GBR traffic having several traffic phases and having different QoS requirements for different traffic phases of the traffic. For example, the traffic has a first traffic phase and a second traffic phase, and has a first QoS requirement for the first traffic phase and a second QoS requirement for the second traffic phase. The QoS requirements may include requirements for QoS parameters such as GBR, MBR, latency, jitter, or error packet rate.
Take online video service as an example. The online video service has a buffering phase as a first service phase and a playing phase as a second service phase. In one example, the online video traffic has a first requirement for GBR1 for the GBR parameter for the buffering phase (e.g., GBR1 is greater than or equal to 6Mbps) and a second requirement for GBR2 for the playback phase (e.g., GBR2 is greater than or equal to 900 Kbps). In one example, GBR1 is set higher than GBR 2.
S220: the first device obtains different QoS requirements for different service stages of the service according to the service type. For example, according to the traffic type, the first device obtains a first QoS requirement for a first traffic phase and a second QoS requirement for a second traffic phase.
S230: the first device generates first indication information. The first indication information indicates different QoS requirements for different traffic phases and traffic phase flags identifying the different traffic phases. For example, the first indication information indicates a first QoS requirement for a first traffic phase, a second QoS requirement for a second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase. The first indication information is used to generate QoS policies for controlling QoS in accordance with first QoS requirements indicated in the QoS policies in a first traffic phase and for controlling QoS in accordance with second QoS requirements indicated in the QoS policies in a second traffic phase.
Advantageously, the first device generates first indication information indicating different QoS requirements for different traffic phases and traffic phase flags identifying the different traffic phases. Based on the first indication, a first traffic phase and a second traffic phase are identified, and a QoS policy is generated to control QoS based on the first QoS requirement in the first traffic phase and the second QoS requirement in the second traffic phase. After receiving the QoS policies, each node in the EPS 200, e.g., UE201, eNB202, MME203, SGW204, or PGW 205, operates traffic according to the desired QoS requirements in each traffic phase. For example, each node in the EPS 200 operates traffic according to a first QoS requirement in a first traffic phase and operates traffic according to a second QoS requirement in a second traffic phase. Taking eNB202 as a more specific example, eNB202 schedules packets at a bit rate of GBR1 in a first traffic phase and schedules packets at a bit rate of GBR2 in a second traffic phase. Taking UE201 as another specific example, similarly, UE201 receives packets at a bit rate of GBR1 in the first traffic phase and at a bit rate of GBR2 in the second traffic phase. Thus, different QoS requirements for different traffic phases of the traffic are met. For example, video traffic is scheduled at GBR of 6Mbps in the buffering stage and 900Kbps in the playing stage. In the buffering phase, a relatively high level of GBR is met to guarantee the user experience. During the playout phase, a relatively low level of GBR is met to keep fewer resources, which can increase the bit rate of other UEs. Accordingly, resources can be efficiently allocated while guaranteeing user experience.
In the first implementation of the embodiment, the service identification module 207 is integrated on the first device 2091, where the first device 2091 includes the UE201, the eNB202, the MME203, the SGW204, or the PGW 205. Thus, as shown in fig. 2B, the method further comprises:
s240: the first device sends the indication information to the PCRF206 according to the first indication information. The indication information is used by the PCRF206 to generate QoS policies. Therefore, the PCRF206 generates the QoS policy according to the indication information, as shown in S820.
S250: after the PCRF206 generates the QoS policies, the first device receives the QoS policies from the PCRF 206.
S260: in a first traffic phase, the first device operates traffic according to first QoS requirements as indicated in the QoS policy.
S270: in a second traffic phase, the first device operates traffic according to second QoS requirements as indicated in the QoS policy.
In a second embodiment of the embodiment, the service identification module 207 is integrated on the first device 2092, and the first device 2092 includes the PCRF 206. Thus, as shown in fig. 2C, the method further comprises:
s280: the first device generates a QoS policy according to the first indication information.
S290: the first device sends the QoS policy to the second device 2093, for example, the second device 2093 may contain the UE201, eNB202, MME203, SGW204, or PGW 205. The QoS policy is for use by the second device to operate traffic according to different QoS requirements in different traffic phases. For example, the QoS policies are used by the second device to operate traffic according to first QoS requirements in a first traffic phase and to operate traffic according to second QoS requirements in a second traffic phase. Thus, the second device operates traffic according to the first QoS requirements in the first traffic phase, as shown in S620, and operates traffic according to the second QoS requirements in the second traffic phase, as shown in S720.
Fig. 3A, 3B, 3C, and 3D show four examples of a method for controlling QoS of traffic. Fig. 3A, 3B, 3C, and 3D are described with respect to fig. 2B. In a first implementation of the embodiment in fig. 2B, the service identification module 207 is integrated on a first device 2091, where the first device 2091 includes the UE201, the eNB202, the MME203, the SGW204, or the PGW 205.
In the example shown in fig. 3A, the first device 2091 receives a message from the third device indicating a service type of the service. For example, the third device includes the service provider 208 in the EPS 200, and performs steps S211, S212, and S213 to implement S210 in fig. 2A.
S211: the service request is received by the service provider 208. For example, when the UE201 starts using a service, e.g., an online video service, the UE201 sends a service request to the service provider 208.
S212: the service provider 208 transmits a message 0 indicating a UE Identity (ID) and a service type of the service to the first device.
S213: after the first device receives message 0 from the service provider 208, the first device obtains the service type of the service.
In another example, when the first device is the UE201, the first device may identify a traffic type of the traffic. For example, when a user starts a service at the UE201, the UE201 is used to identify the service type of the service.
In the example shown in fig. 3A, S221 is performed to implement S220 in fig. 2A.
S221: the first device obtains different QoS requirements aiming at different service stages according to the service type of the service and the user subscription data. In one example, the first device obtains the user subscription data from a Home Subscriber Server (HSS) in the EPS 200 based on the UE ID.
In the example shown in fig. 3A, S231 is performed to implement S230 in fig. 2A.
S231: the first device generates first indication information indicating all QoS requirements for all traffic phases of the traffic and a traffic phase flag identifying the traffic phase. For example, the first indication information indicates a first QoS requirement for the first traffic phase, a second QoS requirement for the second traffic phase, and a traffic phase flag for identifying the first traffic phase and the second traffic phase. Thus, the first indication information may comprise several fields, as shown in table 1.
Figure GDA0002210638600000101
TABLE 1
As shown in table 1, field 1 is used to indicate the traffic type, field 2 is used to indicate the traffic phase flag, and field 3 and field 4 are used to indicate the first QoS requirement for the first traffic phase and the second QoS requirement for the second traffic phase, respectively.
The service phase flags in field 2 are used to identify the different service phases. For example, in one example, the service phase flags are represented in the form of time: the period from the start of the traffic to the time point T1 corresponds to a first traffic phase and the period from the time point T1 to the time point T2 corresponds to a second traffic phase. In another example, the service phase flags are represented in the form of containers: a packet with a packet capacity of X1 calculated from the start of the service corresponds to the first service phase, and a packet with a packet capacity of X2 following the packet with a packet capacity of X1 corresponds to the second service phase. In yet another example, the traffic phase flags are expressed in the form of a combination of time and packet capacity.
Optionally, the first indication information indicating different QoS requirements for different traffic phases is further differentiated according to the level of user experience. For example, the level of user experience includes excellent, good, general, or not good. Taking online video service as an example, when the video service has a fast start speed (less than 2.5 seconds) and is played smoothly, the user experience is excellent. The user experience is good when the video traffic has a normal start speed (less than 4 seconds) and the video is stuck less than 1.5 times per hour. The user experience is general when it takes 4 to 10 seconds to start a video service, or the video is jammed 1.5 to 5 times per hour. In the remaining cases, the user experience is poor.
Each level of user experience corresponds to a different QoS requirement for a different traffic phase. For example, to have an excellent user experience, the GBR requirement for the first traffic phase, e.g. for the buffering phase, is 6Mbit per second and the GBR requirement for the second traffic phase, e.g. for the playing phase, is 900Kbit per second. In order to have a good user experience, the GBR requirement for the first traffic phase is 3Mbit per second and the GBR requirement for the second traffic phase is 720Kbit per second. The set of different QoS requirements corresponding to a particular user experience may be selected based on the user subscription data and the current network state of the EPS 200. Thus, in one example, the first indication information may include several fields, as shown in table 2.
TABLE 2
It should be understood that the first indication information is not limited to the form shown in table 1 or table 2. As long as the first indication information indicates different QoS requirements for different traffic phases of the traffic, it is within the scope of the present invention.
In the example in fig. 3A, the first indication information is used by PCRF206 to generate QoS policies. S241 and S821 are respectively performed to realize S240 and S820 in fig. 2B.
S241: the first device 2091 sends the first indication information to the PCRF 206. The PCRF206 receives the first indication information from the first device 2091.
S821: based on the first indication information, PCRF206 generates QoS policies that indicate traffic phase flags and corresponding different QoS requirements for different traffic phases. In one example, PCRF206 generates QoS policies based on first indication information in the form of table 1. In another example, the PCRF206 selects a user experience based on the user subscription data and the current network state of the EPS 200, and generates a QoS policy corresponding to the selected user experience based on the first indication information in the form of table 2. In both cases, the generated QoS policy is used by the third device to operate traffic according to the first QoS requirements in the first traffic phase and to operate traffic according to the second QoS requirements in the second traffic phase. The third device includes each node in the EPS 200 other than the PCRF206, e.g., the UE201, eNB202, MME203, SGW204, or PGW 205. The third device comprises the first device 2091. In fig. 3A, the QoS policy indicates a first QoS requirement for a first traffic phase, a second QoS requirement for a second traffic phase, and a traffic phase flag.
Subsequently, in S250, the PCRF206 sends the QoS policy to the third device. The QoS policy is sent to the nodes in the EPS 200, for example, by using a bearer establishment method as described in fig. 1A, or by a bearer modification method as described in fig. 1B.
In the example in fig. 3A, the method further comprises:
s310: after receiving the QoS policies, each node (e.g., PGW 205, SGW204, MME203, eNB202, and UE 201) in EPS 200 is configured to identify a traffic phase according to the QoS policies, and further configured to identify QoS requirements for the traffic phase. For example, the PGW 205 identifies a first traffic phase at bearer establishment and a different subsequent traffic phase according to a traffic phase flag as indicated in the QoS policy. As a more specific example, the PGW 205 identifies the different traffic phases following according to at least one of time and data capacity. When the time T1 expires and/or the packet capacity X1 is reached, the PGW 205 identifies the second traffic phase. After identifying the traffic phase, the PGW 205 is configured to identify QoS requirements for the traffic phase according to the received QoS policy. How other nodes in EPS 200 recognize traffic phases and the QoS requirements of the traffic phases are similar to PGW 205 and will not be repeated here.
Thus, each node in the EPS 200 operates traffic according to the first QoS requirements in a first traffic phase in S260 and operates traffic according to the second QoS requirements in a second traffic phase in S270. For example, in the first traffic phase, SGW204 forwards user's packets at the bit rate of GBR1, and eNB202 schedules the packets at the bit rate of GBR 1. In the second traffic phase, SGW204 forwards the user's packets at the bit rate of GBR2, which eNB202 schedules at the bit rate of GBR 2.
Fig. 3B illustrates another example of a method for controlling QoS of traffic. Fig. 3B is described with respect to fig. 2B and 3A.
In the example shown in fig. 3B, S210, S220, S231, and S241 are performed. Examples of how S210, S220, S231, and S241 are performed have been described in fig. 3A, and will not be repeated here. The first indication information is used by PCRF206 to identify a traffic phase and QoS requirements for the traffic phase and further generate QoS policies. Accordingly, S822 to 824 and S251 to S252 are respectively performed to realize S820 and S250 in fig. 2B.
S822: the PCRF206 identifies the traffic phase and the QoS requirements for the traffic phase according to the first indication information. For example, PCRF206 identifies a first traffic phase at bearer establishment. After identifying the first traffic phase, PCRF206 is configured to identify a first QoS requirement for the first traffic phase in accordance with the first indication information. The PCRF206 identifies the different subsequent traffic phases according to the traffic phase flag in the first indication information. For example, PCRF206 identifies the second traffic phase based on at least one of time or data capacity. When time T1 expires and/or packet capacity X1 is reached, PCRF206 identifies the second traffic phase. After identifying the second traffic phase, PCRF206 is configured to identify second QoS requirements for the second traffic phase in accordance with the first indication information.
S823: when the PCRF206 identifies the first traffic phase and the first QoS requirements for the first traffic phase, the PCRF206 generates a first QoS policy according to the first QoS requirements for the first traffic phase. The first QoS policy may be generated in the form of an existing QoS policy without modification. The first QoS policy is for use by the third device to operate traffic in accordance with the first QoS requirements in the first traffic phase.
S251: a third device, e.g., each node in the EPS 200, receives the first QoS policy from the PCRF 206. Accordingly, each node in the EPS 200 operates traffic according to the first QoS requirements in the first traffic phase, as described in S260. For example, in the first traffic phase, SGW204 forwards user's packets at the bit rate of GBR1, and eNB202 schedules the packets at the bit rate of GBR 1.
S824: when the PCRF206 identifies the second traffic phase and the second QoS requirements for the second traffic phase, the PCRF206 generates a second QoS policy according to the second QoS requirements for the second traffic phase. The second QoS policy may also be generated in the form of an existing QoS policy without modification. The second QoS policy is for use by the third device to operate traffic in accordance with the second QoS requirements in the second traffic phase.
S252: a third device, e.g., each node in the EPS 200, receives the second QoS policy from the PCRF 206. Accordingly, each node in the EPS 200 containing the first device operates traffic according to the second QoS requirements in the second traffic phase, as described in S270. For example, in the second traffic phase, SGW204 forwards user's packets at the bit rate of GBR2, which eNB202 schedules at the bit rate of GBR 2.
Advantageously, resources can be efficiently allocated while ensuring the user experience. Furthermore, since the PCRF206 is configured to identify traffic phases and corresponding different QoS requirements for the traffic phases, the QoS policies generated by the PCRF206 can be implemented in the form of existing QoS policies without any modification. Thus, the generated QoS policy does not need to take into account the traffic phase flags and the corresponding QoS requirements for the different traffic phases.
Fig. 3C shows another example of a method for controlling QoS of traffic. Fig. 3C is described with respect to fig. 2B.
In the example of fig. 3C, S210, S220, and S231 are performed. Examples of how S210, S220, and S231 are performed have been described in fig. 3A, and will not be repeated here.
In the example shown in fig. 3C, the method further includes S232-S234. S242 to S243 and S825 to S826 are respectively performed to implement S240 and S820 in fig. 2B.
S232: the first device identifies a first QoS requirement for the first traffic phase based on the first indication information.
S233: the first device generates second indication information indicating the first QoS requirements for the first traffic phase.
S242: the first device sends the second indication information to PCRF 206. The second indication information is used by PCRF206 to generate a first QoS policy that indicates first QoS requirements for the first traffic phase.
S825: the PCRF206 generates the first QoS policy according to the second indication information. The first QoS policy may be generated in the form of an existing QoS policy without modification.
S251: the first device receives a first QoS policy. Accordingly, each node in the EPS 200 operates traffic according to the first QoS requirements in the first traffic phase, as described in S260.
S234: the first device identifies a second QoS requirement for the second traffic phase based on the first indication information.
S235: the first device generates third indication information indicating a second QoS requirement for the second traffic phase.
S243: the first device sends the third indication information to PCRF 206. The third indication information is used by PCRF206 to generate a second QoS policy that indicates second QoS requirements for the second traffic phase.
S826: the PCRF206 generates a second QoS policy according to the third indication information. The second QoS policy may also be generated in the form of an existing QoS policy without modification.
S252: the first device receives a second QoS policy. Accordingly, each node in the EPS 200 operates traffic according to the second QoS requirements in the second traffic phase, as described in S270.
In the example shown in fig. 3C, the first device is further configured to identify traffic phases and thereby identify different QoS requirements.
For example, in fig. 3C, S2321 and S2341 are performed to implement S232 and S234, respectively.
S2321: the first device identifies the first traffic phase according to the traffic phase flag indicated in the first indication information, thereby identifying a first QoS requirement for the first traffic phase. For example, the first device identifies a first traffic phase at bearer establishment. After identifying the first traffic phase, the first device is to identify a first QoS requirement for the first traffic phase.
S2341: the first device identifies the second traffic phase according to the traffic phase flag indicated in the first indication information, thereby identifying a second QoS requirement for the second traffic phase. For example, the first device identifies the second traffic phase as a function of at least one of time or data capacity. When time T1 expires and/or packet capacity X1 is reached, the first device identifies the second traffic phase. After identifying the second traffic phase, the first device is to identify second QoS requirements for the second traffic phase.
Advantageously, resources can be efficiently allocated while ensuring the user experience. Furthermore, since the first device is used to identify the traffic phase, it sends second indication information indicating the first QoS requirements to the PCRF206 when identifying the first traffic phase and sends third indication information indicating the second QoS requirements to the PCRF206 when identifying the second traffic phase. Based on the received indication information, PCRF206 generates QoS policies that indicate QoS requirements for the traffic phases. Thus, the generated QoS policies may be implemented in the form of existing QoS policies without any modification. Thus, the generated QoS policy does not need to take into account the traffic phase flags and the corresponding QoS requirements for the different traffic phases.
Fig. 3D shows yet another example of a method for controlling QoS of traffic. Fig. 3D is described with respect to fig. 3C. The same steps labeled as in fig. 3C are performed in a similar manner.
In fig. 3D, S232 and S234 are implemented only by a plurality of additional steps. S2322 to S2324 and S2342 to S2343 are executed to realize S232 and S234.
S2322: the first device sends a request to activate the UE201 to identify the first traffic phase and the second traffic phase (when the first device is not the UE 201).
In one example, after activating the UE201, the UE201 identifies a traffic phase according to at least one of software operating instructions and state information. Still taking the video service as an example, the UE201 identifying the service phase according to the software operation instruction includes: when the user clicks on the icon to start the video service in the UE201, the UE201 recognizes that the video service enters a first service phase, e.g., an initial phase. The UE201 identifies the service phase according to the state information, including: when the data capacity in the buffer reaches a threshold, e.g., set to 70% of the buffer capacity, the UE201 recognizes that the video traffic enters a second traffic phase, e.g., a playback phase.
In another example, the request includes information indicating a traffic phase flag. The traffic phase flags are used by the UE201 to identify different traffic phases. The traffic phase flag may be expressed in the form of at least one or a combination of time and packet capacity, as described above. Accordingly, the UE201 identifies the traffic phase according to at least one of time and packet capacity.
S2323: when the UE201 identifies the first traffic phase, the first device receives a feedback message 4 reported by the UE201 indicating that the traffic phase is the first traffic phase.
S2324: after receiving the feedback message 4 reported by the UE201, the first device identifies a first QoS requirement for the first traffic phase.
S2342: when the UE201 identifies the second traffic phase, the first device receives a feedback message 5 reported by the UE201 indicating that the traffic phase is the second traffic phase.
S2343: after receiving message 5 reported by UE201, the first device identifies a second QoS requirement for the second traffic phase.
Advantageously, since the first device activates the UE201 to identify the traffic phase, the first device sends second indication information indicating the first QoS requirements to the PCRF206 when the UE201 identifies the first traffic phase and sends third indication information indicating the second QoS requirements to the PCRF206 when the UE201 identifies the second traffic phase. Based on the received indication information, PCRF206 generates QoS policies that indicate QoS requirements for the traffic phases. Thus, the QoS policies generated by PCRF206 may be implemented in the form of existing QoS policies without any modification. Thus, the generated QoS policy does not need to take into account the traffic phase flags and the corresponding QoS requirements for the different traffic phases.
Fig. 4A, 4B, and 4C show three additional examples of methods for controlling QoS of traffic. Fig. 4A, 4B, and 4C are described with respect to fig. 2C. In a second implementation of the embodiment in fig. 2C, the traffic identification module 207 is integrated on the first device 2092 that contains the PCRF 206.
In fig. 4A, S211 to S213, S221, and S231 are performed. An example of how the first device 2092 performs the above steps is similar to the first device 2091 and will not be repeated here. In the example of fig. 4A, the first indication is used by the first device 2092 to generate the QoS policy. After the first device 2092 generates the first indication information in S231, S281 is performed to implement S280 in fig. 2C.
S281: the first device 2092 generates the QoS policy based on the first indication. The QoS policy indicates a first QoS requirement for a first traffic phase, a second QoS requirement for a second traffic phase, and a traffic phase flag. The example of how the first device 2092 generates QoS policies indicating a first QoS requirement for a first traffic phase, a second QoS requirement for a second traffic phase, and a traffic phase flag is similar to how the PCRF206 generates QoS policies as described in S821 and will not be repeated here. Subsequently, the first device transmits the QoS policy to the second device, as described in S290. The second device receives the QoS policy from the first device. The QoS policy is used by the second device to identify the traffic phase.
In S320, the second device identifies the traffic phase and the QoS requirements of the traffic phase according to the QoS policy. How the second device 2093 identifies the service phase based on the QoS policy is similar to how the first device 2091 identifies the service phase as described in S310 and will not be repeated here. Thus, the second device operates traffic according to the first QoS requirements in the first traffic phase, as described in S620, and operates traffic according to the second QoS requirements in the second traffic phase, as described in S720.
Fig. 4B illustrates another example of a method for controlling QoS of traffic. Fig. 4B is described with respect to fig. 4A and 2C.
In the example shown in fig. 4B, S210, S220, and S231 are performed. Examples of how S210, S220, and S231 are performed have been described in fig. 3A, and will not be repeated here.
In the example shown in fig. 4B, the first indication information is used by a first device, such as PCRF206, to identify QoS requirements and generate QoS policies accordingly. S282 to S285 and S291 to S292 are respectively performed to realize S280 and S290 in fig. 2C.
S282: the first device identifies a first QoS requirement for the traffic phase according to the first indication information. In fig. 4B, S2821 is performed to implement S282.
S2821: the first device identifies a first traffic phase and thereby further identifies a first QoS requirement for the traffic phase. For example, the first device identifies the first traffic phase by default at bearer establishment. After identifying the first traffic phase, the first device identifies a first QoS requirement for the first traffic phase according to the first indication information.
S283: when the first device identifies the first traffic phase, the first device generates a first QoS policy based on first QoS requirements for the first traffic phase. The first QoS policy may be generated as an existing QoS policy without modification.
S291: the first device sends the first QoS policy to the second device in the EPS 200, and thus, the second device operates the traffic according to the first QoS requirements in the first traffic phase, as described in S620. For example, in the first traffic phase, SGW204 forwards user's packets at the bit rate of GBR1, and eNB202 schedules the packets at the bit rate of GBR 1.
S284: the first device identifies a second QoS requirement for the second traffic phase. In fig. 4B, S2841 is performed to implement S284.
S2841: the first device identifies a traffic phase based on the first indication information, thereby further identifying a second QoS requirement for the traffic phase. For example, the first device identifies the different service phases following the first indication according to the service phase flag in the first indication information. As a more particular example, the first device identifies the second traffic phase as a function of at least one of time or data capacity. When time T1 expires and/or packet capacity X1 is reached, PCRF206 identifies the second traffic phase. After identifying the second traffic phase, the first device identifies a second QoS requirement for the second traffic phase according to the first indication information.
S285: the first device generates a second QoS policy based on second QoS requirements for the second traffic phase. The second QoS policy may also be generated in the form of an existing QoS policy without modification.
S292: the first device 2092 sends the second QoS policy to the second device, and the second device operates the service according to the second QoS requirements in the second service phase, as described in S720. For example, in the second traffic phase, SGW204 forwards user's packets at the bit rate of GBR2, which eNB202 schedules at the bit rate of GBR 2.
Fig. 4C shows yet another example of a method for controlling QoS of traffic. Fig. 4C is described with respect to fig. 4B. The same steps labeled as in fig. 3C are performed in a similar manner.
In fig. 4C, S282 and S284 are implemented only by a plurality of additional steps. S2822 to S2824 and S2842 to S2843 are performed to implement S282 and S284.
S2822: the first device sends a request to activate the UE201 to identify the traffic phase. An example of how the UE201 identifies the traffic phase has been described in S2322 and will not be described here.
S2823: when the UE201 identifies the first traffic phase, the first device receives a feedback message 4 reported by the UE201 indicating that the traffic phase is the first traffic phase.
S2824: after receiving the feedback message 4 reported by the UE201, the first device identifies a first QoS requirement for the first traffic phase.
S2842: when the UE201 identifies the second traffic phase, the first device receives a feedback message 5 reported by the UE201 indicating that the traffic phase is the second traffic phase.
S2843: after receiving message 5 reported by UE201, the first device identifies a second QoS requirement for the second traffic phase.
Fig. 5 shows a simplified block diagram of an apparatus 502 for controlling QoS of traffic. Fig. 5 is described with respect to fig. 2A. The device 502 may be any node in the EPS 200, e.g., UE201, eNB202, MME203, SGW204, PGW 205, or PCRF 206.
As shown in fig. 5, the apparatus 502 comprises a first acquisition unit 506, a second acquisition unit 508 and a generation unit 510. The first obtaining unit 506, the second obtaining unit 508 and the generating unit 510 may be implemented by a processor in a node of the device 502, for example. As used herein, the term "processor" refers to one or more devices, circuits, and/or processing cores, such as computer program instructions, for processing data.
The first obtaining unit 506 is configured to obtain a service type of a service. The traffic comprises GBR traffic having at least a first traffic phase and a second traffic phase. The second obtaining unit 508 is configured to obtain a first QoS requirement for the first service phase and a second QoS requirement for the second service phase according to the service type of the service. The generating unit 510 is configured to generate first indication information indicating a first QoS requirement for a first traffic phase, a second QoS requirement for a second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase. For example, the traffic phase flag is expressed in the form of any one or any combination of the time of a data packet and the packet capacity of the data packet. The first indication information is used to generate QoS policies for controlling QoS in accordance with first QoS requirements indicated in the QoS policies in a first traffic phase and for controlling QoS in accordance with second QoS requirements indicated in the QoS policies in a second traffic phase.
In one example, the first indication information indicates a first QoS requirement for a first traffic phase and a second QoS requirement for a second traffic phase, the QoS requirements corresponding to a first level of user experience for the traffic, the first indication information further indicates a third QoS requirement for the first traffic phase and a fourth QoS requirement for the second traffic phase, the QoS requirements corresponding to a second level of user experience for the traffic.
Advantageously, the first device generates first indication information indicating different QoS requirements for different traffic phases and traffic phase flags identifying the different traffic phases. Based on the first indication, a first traffic phase and a second traffic phase are identified, and a QoS policy is generated to control QoS according to the first QoS requirement in the first traffic phase and according to the second QoS requirement in the second traffic phase. After receiving the QoS policies, each node in the EPS 200, e.g., UE201, eNB202, MME203, SGW204, or PGW 205, operates traffic according to the desired QoS requirements in each traffic phase. For example, each node in the EPS 200 operates traffic according to a first QoS requirement in a first traffic phase and operates traffic according to a second QoS requirement in a second traffic phase. Taking eNB202 as a more specific example, eNB202 schedules packets at a bit rate of GBR1 in a first traffic phase and schedules packets at a bit rate of GBR2 in a second traffic phase. Thus, different QoS requirements for different traffic phases of the traffic are met. For example, video traffic is scheduled at GBR of 6Mbps in the buffering stage and 900Kbps in the playing stage. In the buffering phase, a relatively high level of GBR is met to guarantee the user experience. During the playout phase, a relatively low level of GBR is met to keep fewer resources, which can increase the bit rate of other UEs. Accordingly, resources can be efficiently allocated while guaranteeing user experience.
Fig. 6A, 6B, and 6C show three examples of an apparatus for controlling QoS of traffic. Fig. 6A, 6B, and 6C are described with respect to fig. 5. Like-labeled elements perform similar functions.
In fig. 6A and 6B, the apparatus 602 for controlling QoS of traffic is implemented by the UE201, eNB202, MME203, SGW204, or PGW 205. The apparatus 602 comprises a first obtaining unit 506, a second obtaining unit 508, a generating unit 510, a QoS receiving unit 604 and a service operating unit 608.
The QoS receiving unit 604 is configured to receive the QoS policy from the PCRF 206. The traffic operation unit 608 is configured to operate traffic according to a first QoS requirement indicated in the QoS policy in a first traffic phase and to operate traffic according to a second QoS requirement indicated in the QoS policy in a second traffic phase.
In fig. 6A, the generating unit 510 is further configured to send the first indication information to the PCRF 206. The first indication information is used by PCRF206 to generate QoS policies. In one example, the QoS policy generated by PCRF206 indicates a first QoS requirement for a first traffic phase, a second QoS requirement for a second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase. Thus, the apparatus 602 further comprises a first identification unit 610. The first identifying unit 610 is configured to identify a first service phase and a second service phase according to a service phase flag indicated in the QoS policy, so that the first device can operate the service according to a first QoS requirement indicated in the QoS policy in the first service phase and operate the service according to a second QoS requirement indicated in the QoS policy in the second service phase.
In another example, the first indication information is used by PCRF206 to identify traffic phases and generate QoS policies. When the PCRF206 identifies the first traffic phase and the first QoS requirement for the first traffic phase according to the first indication information, the PCRF generates a first QoS policy. Thus, the apparatus 600 operates traffic according to the first QoS requirements in accordance with the first QoS policy in the first traffic phase. When PCRF206 identifies the second traffic phase and the second QoS requirements for the second traffic phase based on the first indication information, the PCRF generates a second QoS policy. Accordingly, the device 600 operates traffic in accordance with the second QoS requirements in accordance with the second QoS policy in the second traffic phase.
In fig. 6B, the apparatus 614 further comprises a second identification unit 616. The second identifying unit 616 is configured to identify a first QoS requirement for the first traffic phase and a second QoS requirement for the second traffic phase according to the first indication information. Accordingly, the generating unit 510 is configured to generate second indication information indicating the first QoS requirements for the first traffic phase upon identifying the first QoS requirements for the first traffic phase, and send the second indication information to the PCRF206 to generate the first QoS policy. The generating unit 510 is configured to generate third indication information indicating the second QoS requirement for the second traffic phase when the second QoS requirement for the second traffic phase is identified, and send the third indication information to the PCRF206 to generate the second QoS policy.
In one example, the second identifying unit 616 is configured to identify the first traffic phase according to the traffic phase flag indicated in the first indication information, thereby identifying a first QoS requirement for the first traffic phase, and identify the second traffic phase according to the traffic phase flag indicated in the first indication information, thereby identifying a second QoS requirement for the second traffic phase.
In another example, the second identifying unit 616 is configured to send a request to a User Equipment (UE) to activate the UE to identify the first traffic phase and the second traffic phase, receive a first feedback message from the UE indicating that the first traffic phase is identified, and identify the first QoS requirement for the first traffic phase according to the first feedback message. The second identifying unit 616 is further configured to receive a second feedback message from the UE indicating that the second traffic phase is identified, and identify a second QoS requirement for the second traffic phase according to the second feedback message.
In fig. 6C, the means 630 for controlling the QoS of the traffic is implemented by the PCRF 206. The apparatus 630 includes a first acquisition unit 506, a second acquisition unit 508, a generation unit 510, and a QoS generation unit 632. The QoS generation unit 632 is configured to generate a QoS policy according to the first indication information and send the QoS policy to a second device, for example, the UE201, the eNB202, the MME203, the SGW204, or the PGW 205. The QoS policies are used by the second device to operate traffic according to the first QoS requirements in the first traffic phase and to operate traffic according to the second QoS requirements in the second traffic phase.
In one example, the device 630 generates a QoS policy that indicates a first QoS requirement for a first traffic phase, a second QoS requirement for a second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase. Thus, the second device identifies the first traffic phase and the second traffic phase according to the traffic phase flag indicated in the QoS policy, so that the second device is able to operate traffic according to the first QoS requirement indicated in the QoS policy in the first traffic phase and operate traffic according to the second QoS requirement indicated in the QoS policy in the second traffic phase.
In another example, the apparatus 630 further comprises a third identification unit 634. The third identifying unit 634 is used for identifying a first QoS requirement for the first traffic phase and a second QoS requirement for the second traffic phase according to the first indication information. Thus, the QoS generation unit 632 is configured to generate a first QoS policy according to a first QoS requirement for a first traffic phase when the first QoS requirement for the first traffic phase is identified, and to generate a second QoS policy according to a second QoS requirement for a second traffic phase when the second QoS requirement for the second traffic phase is identified.
For example, in one example, the third identifying unit 634 is configured to identify a first traffic phase according to a traffic phase flag indicated in the first indication information, so as to identify a first QoS requirement for the first traffic phase, and identify a second traffic phase according to a traffic phase flag indicated in the first indication information, so as to identify a second QoS requirement for the second traffic phase.
In another example, the third identifying unit 634 is configured to send a request to a User Equipment (UE) to activate the UE to identify the first traffic phase and the second traffic phase, receive a first feedback message from the UE indicating that the first traffic phase is identified, and identify the first QoS requirement for the first traffic phase according to the first feedback message. The third identifying unit 634 is further configured to receive a second feedback message from the UE indicating that the second traffic phase is identified, and identify a second QoS requirement for the second traffic phase according to the second feedback message.
Fig. 7A and 7B show two simplified block diagrams of a second apparatus for controlling QoS of traffic. The traffic comprises GBR traffic having at least a first traffic phase and a second traffic phase. In fig. 7A, the second device 700 comprises a receiving unit 702, a generating unit 704 and a sending unit 706. The apparatus 700 may be implemented by a PCRF, for example, by the PCRF206 in fig. 3A and 3B. The receiving unit 702, the generating unit 704, and the sending unit 706 may be implemented by a processor in the PCRF 206.
The receiving unit 702 is configured to receive first indication information from a first device. The first indication information indicates a first QoS requirement for the first traffic phase, a second QoS requirement for the second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase.
The generating unit 704 is configured to generate the QoS policy according to the first indication information. The sending unit 706 is configured to send the QoS policy to the third device. The QoS policies are used by the third device to operate traffic according to the first QoS requirements in the first traffic phase and to operate traffic according to the second QoS requirements in the second traffic phase. The third device comprises the first device.
In one example, the QoS policy indicates a first QoS requirement for a first traffic phase, a second QoS requirement for a second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase. The QoS policy is used by the third device to identify the first traffic phase and the second traffic phase based on the traffic phase flag indicated in the QoS policy.
In another example, optionally, the apparatus 700 further comprises an identification unit 708. The identifying unit 708 is configured to identify the first traffic phase and a first QoS requirement for the first traffic phase according to the first indication information. The generating unit 704 is configured to generate a first QoS policy according to the first QoS requirement for the first traffic phase, the first QoS policy being used by the third device to operate traffic according to the first QoS requirement in the first traffic phase. The generating unit 704 is further configured to generate a second QoS policy according to a second QoS requirement for the second traffic phase, the second QoS policy being used by the third device to operate traffic according to the second QoS requirement in the second traffic phase.
In the example of fig. 7B, the apparatus 710 includes a receiving unit 712, an identifying unit 714, and an operating unit 716. The device 710 may be implemented by any node in the EPS 200, for example, by the second device 2093 in fig. 4A. The receiving unit 712, the identifying unit 714 and the operating unit 716 may be implemented by a processor in the second device 2093.
The receiving unit 712 is configured to receive the QoS policy from the first device. The QoS policy indicates a first QoS requirement for a first traffic phase, a second QoS requirement for a second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase.
The identifying unit 714 is configured to identify the first traffic phase according to the traffic phase flag indicated in the QoS policy, and to identify a first QoS requirement for the first traffic phase. The operation unit 716 is configured to operate the traffic in accordance with the first QoS requirement in the first traffic phase according to the QoS policy. The identifying unit 714 is further configured to identify a second traffic phase according to the traffic phase flag indicated in the QoS policy, and to identify a second QoS requirement for the second traffic phase. The operation unit 716 is further configured to operate the traffic in the second traffic phase according to the second QoS requirements according to the QoS policy.
Those of ordinary skill in the art will appreciate that the elements and algorithm steps described in connection with the examples disclosed in this specification may be embodied in electronic hardware or in a combination of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.
It will be clearly understood by those skilled in the art that for the sake of convenience and simplicity of description, reference may be made to corresponding processes in the foregoing method embodiments for the detailed working of the foregoing systems, devices and units, and details will not be described herein.
In several embodiments provided in the present application, it should be understood that the disclosed systems, devices, and methods may be implemented in other ways. For example, the described apparatus embodiments are merely exemplary. For example, the cell partitions are merely logical functional partitions and may be other partitions in an actual implementation. For example, various elements or components may be combined or integrated in another system or portions of features may be omitted, or not implemented. Further, the shown or discussed mutual coupling or direct coupling or communicative connection may be achieved through some interfaces. Direct coupling or communicative connection between devices or units may be achieved through electrical, mechanical, or other means.
Units described as separate parts may or may not be physically separate, and parts described as units may or may not be physical units, may be located in one position or may be distributed over a plurality of network units. Some or all of the units may be selected according to actual requirements to achieve the purpose of the solution in the embodiments.
In addition, the functional units in the embodiments of the present invention may be integrated into one processing unit, or each unit may be physically present separately, or two or more units may be integrated into one unit.
These functions may be stored in a computer-readable storage medium when they are implemented in the form of software functional units and sold or used as separate products. The solution according to the invention may be implemented substantially as such or as constituting part of the prior art or part of the solution according to the invention in the form of a software product. A computer software product is stored in a storage medium and contains instructions for instructing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method described in the embodiments of the present invention. The storage medium includes: any medium that can store program code, such as a USB disk, a removable hard disk, a Read-Only Memory (ROM), a Random-Access Memory (RAM), a magnetic disk, or an optical disk.
The above description is only a specific embodiment of the present invention and is not intended to limit the scope of the present invention. Any variations or substitutions which may be easily found by those skilled in the art within the technical scope of the present invention disclosed herein are intended to fall within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.

Claims (40)

1. A method for controlling quality of service (QoS) of a service, comprising:
the method comprises the steps that first equipment obtains a service type of the service, wherein the service comprises Guaranteed Bit Rate (GBR) service with at least a first service stage and a second service stage;
the first equipment acquires a first QoS requirement aiming at the first service phase and a second QoS requirement aiming at the second service phase according to the service type of the service; and
the first device generates first indication information, wherein the first indication information indicates the first QoS requirements for the first traffic phase, the second QoS requirements for the second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase, wherein the first indication information is used to generate QoS policies to control QoS in the first traffic phase according to the first QoS requirements indicated in the QoS policies and to control QoS in the second traffic phase according to the second QoS requirements indicated in the QoS policies.
2. The method of claim 1, wherein the service phase flag is represented in any one or any combination of the following forms: the time of the data packet and the packet's capacity.
3. The method of claim 1, wherein the first indication information indicates the first QoS requirement for the first traffic phase and the second QoS requirement for the second traffic phase, wherein the first QoS requirement and the second QoS requirement correspond to a first level of user experience for the traffic, and wherein the first indication information further indicates a third QoS requirement for the first traffic phase and a fourth QoS requirement for the second traffic phase, wherein the third QoS requirement and the fourth QoS requirement correspond to a second level of user experience for the traffic.
4. The method of claim 2, wherein the first indication information indicates the first QoS requirement for the first traffic phase and the second QoS requirement for the second traffic phase, the first QoS requirement and the second QoS requirement corresponding to a first level of user experience for the traffic, and wherein the first indication information further indicates a third QoS requirement for the first traffic phase and a fourth QoS requirement for the second traffic phase, the third QoS requirement and the fourth QoS requirement corresponding to a second level of user experience for the traffic.
5. The method according to any one of claims 1 to 4, characterized in that the method further comprises:
the first device receiving the QoS policy from a Policy and Charging Rules Function (PCRF);
the first device operating the traffic in the first traffic phase according to the first QoS requirement indicated in the QoS policy; and
the first device operates the traffic in the second traffic phase according to the second QoS requirements indicated in the QoS policy.
6. The method of claim 5, further comprising:
the first device sending the first indication information to the PCRF, wherein the first indication information is used by the PCRF to generate the QoS policy;
the first device identifies the first service phase and the second service phase according to the service phase flag indicated in the QoS policy.
7. The method of claim 5, further comprising:
the first device identifies the first QoS requirement for the first traffic phase according to the first indication information;
generating, by the first device, second indication information indicating the first QoS requirement for the first traffic phase, wherein the second indication information is sent to the PCRF and used by the PCRF to generate a first QoS policy indicating the first QoS requirement for the first traffic phase;
the first device identifies the second QoS requirement for the second traffic phase according to the first indication information;
the first device generates third indication information indicating the second QoS requirements for the second traffic phase, wherein the third indication information is sent to the PCRF and used by the PCRF to generate a second QoS policy indicating the second QoS requirements for the second traffic phase.
8. The method of claim 7, wherein identifying the first QoS requirement for the first traffic phase comprises:
the first device sending a request to activate a User Equipment (UE) to identify the first traffic phase and the second traffic phase;
the first equipment receives a first feedback message reported by the UE, wherein the first feedback message indicates that the first service phase is identified;
the first device identifying the first QoS requirement for the first traffic phase from the first feedback message;
wherein identifying the second QoS requirement for the second traffic phase comprises:
the first equipment receives a second feedback message reported by the UE, wherein the second feedback message indicates that the second service phase is identified;
the first device identifies the second QoS requirement for the second traffic phase from the second feedback message.
9. A method for controlling quality of service of a service, the method having any one of claims 1 to 7, wherein the first device includes a User Equipment (UE), an evolved NodeB (eNodeB), a Mobility Management Entity (MME), a Serving Gateway (SGW), or a packet data network gateway (PGW).
10. A method for controlling quality of service of a service, characterized in that the method has the method of any of claims 1 to 4, and that the first device comprises a Policy and Charging Rules Function (PCRF);
wherein the method further comprises:
the first device generates the QoS policy according to the first indication information; and
the first device sends the QoS policy to a second device, wherein the QoS policy is for use by the second device to operate the traffic according to the first QoS requirements in the first traffic phase and to operate the traffic according to the second QoS requirements in the second traffic phase.
11. The method of claim 10, wherein the generated QoS policy indicates the first QoS requirement for the first traffic phase, the second QoS requirement for the second traffic phase, and the traffic phase flag identifying the first traffic phase and the second traffic phase, wherein the QoS policy is used by the second device to identify the first traffic phase and the second traffic phase.
12. The method of claim 10, wherein generating the QoS policy according to the first indication information comprises:
the first device identifies the first QoS requirement for the first traffic phase according to the first indication information;
the first device generating a first QoS policy according to the first QoS requirement;
the first device identifies the second QoS requirement for the second traffic phase according to the first indication information; and
the first device generates a second QoS policy according to the second QoS requirement.
13. The method of claim 12, wherein identifying the first QoS requirement for the first traffic phase comprises:
the first device sending a request to activate a User Equipment (UE) to identify the first traffic phase and the second traffic phase;
the first equipment receives a first feedback message reported by the UE, wherein the first feedback message indicates that the first service phase is identified;
the first device identifying the first QoS requirement for the first traffic phase from the first feedback message;
wherein identifying the second QoS requirement for the second traffic phase comprises:
the first equipment receives a second feedback message reported by the UE, wherein the second feedback message indicates that the second service phase is identified;
the first device identifies the second QoS requirement for the second traffic phase from the second feedback message.
14. A method for controlling quality of service of a service, characterized in that the method has the method of any of claims 1 to 13, and obtaining the service type of the service comprises:
the first device receives a message from a third device indicating the traffic type of the traffic.
15. A first apparatus for controlling quality of service (QoS) of a service, comprising:
a first obtaining unit, configured to obtain a service type of the service, where the service is a Guaranteed Bit Rate (GBR) service having at least a first service phase and a second service phase;
a second obtaining unit, configured to obtain, according to the service type of the service, a first QoS requirement for the first service phase and a second QoS requirement for the second service phase; and
a generating unit configured to generate first indication information indicating the first QoS requirement for the first traffic phase, the second QoS requirement for the second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase, wherein the first indication information is used to generate a QoS policy to control QoS in the first traffic phase according to the first QoS requirement indicated in the QoS policy, and to control QoS in the second traffic phase according to the second QoS requirement indicated in the QoS policy.
16. The first device of claim 15, wherein the traffic phase flag is represented in any one or any combination of the following: the time of the data packet and the packet's capacity.
17. The first device of claim 15, wherein the first indication information indicates the first QoS requirements for the first traffic phase and the second QoS requirements for the second traffic phase, wherein the first QoS requirements and the second QoS requirements correspond to a first level of user experience for the traffic, and wherein the first indication information further indicates a third QoS requirements for the first traffic phase and a fourth QoS requirements for the second traffic phase, wherein the third QoS requirements and the fourth QoS requirements correspond to a second level of user experience for the traffic.
18. The first device of claim 16, wherein the first indication information indicates the first QoS requirements for the first traffic phase and the second QoS requirements for the second traffic phase, wherein the first QoS requirements and the second QoS requirements correspond to a first level of user experience for the traffic, and wherein the first indication information further indicates a third QoS requirements for the first traffic phase and a fourth QoS requirements for the second traffic phase, wherein the third QoS requirements and the fourth QoS requirements correspond to a second level of user experience for the traffic.
19. The first apparatus of any of claims 15-18, further comprising:
a QoS receiving unit for receiving the QoS policy from a Policy and Charging Rules Function (PCRF); and
a service operation unit, configured to operate the service according to the first QoS requirement indicated in the QoS policy in the first service phase, and operate the service according to the second QoS requirement indicated in the QoS policy in the second service phase.
20. The first apparatus of claim 19, wherein the generating unit is configured to send the first indication information to the PCRF, wherein the first indication information is used by the PCRF to generate the QoS policy;
wherein the apparatus further comprises:
a first identification unit, configured to identify the first service phase and the second service phase according to the service phase flag indicated in the QoS policy.
21. The first device of claim 19, further comprising:
a second identification unit, configured to identify the first QoS requirement for the first traffic phase and the second QoS requirement for the second traffic phase according to the first indication information;
wherein the generating unit is to generate second indication information indicating the first QoS requirement for the first traffic phase when the first QoS requirement for the first traffic phase has been identified and to send the second indication information to the PCRF to generate a first QoS policy, and wherein the generating unit is to generate third indication information indicating the second QoS requirement for the second traffic phase when the second QoS requirement for the second traffic phase has been identified and to send the third indication information to the PCRF to generate a second QoS policy.
22. The first apparatus of claim 21, wherein the second identifying unit is configured to send a request to a User Equipment (UE) to activate the UE to identify the first traffic phase and the second traffic phase, to receive a first feedback message from the UE indicating that the first traffic phase is identified, and to identify the first QoS requirement for the first traffic phase based on the first feedback message;
wherein the second identifying unit is further configured to receive a second feedback message from the UE indicating that the second traffic phase is identified, and identify the second QoS requirement for the second traffic phase according to the second feedback message.
23. A first device, characterized in that the first device has all the features of the first device of any one of claims 15 to 21, and in that the device comprises a User Equipment (UE), an evolved NodeB (eNodeB), a Mobility Management Entity (MME), a Serving Gateway (SGW), or a packet data network gateway (PGW).
24. A first device, characterized in that it has all the features of the first device of any of claims 15 to 18, and in that it comprises a Policy and Charging Rules Function (PCRF) comprising;
a QoS generating unit configured to generate the QoS policy according to the first indication information and send the QoS policy to a second device, wherein the QoS policy is used by the second device to operate the service according to the first QoS requirement in the first service phase and operate the service according to the second QoS requirement in the second service phase.
25. The first device of claim 24, wherein the QoS policy indicates the first QoS requirement for the first traffic phase, the second QoS requirement for the second traffic phase, and the traffic phase flag for use by the second device to identify the first traffic phase and the second traffic phase.
26. The first device of claim 24, further comprising:
a third identifying unit, configured to identify the first QoS requirement for the first traffic phase and the second QoS requirement for the second traffic phase according to the first indication information;
wherein the QoS policies comprise a first QoS policy and a second QoS policy, the QoS generation unit to generate the first QoS policy according to the first QoS requirement for the first traffic phase when the first QoS requirement for the first traffic phase has been identified, and to generate the second QoS policy according to the second QoS requirement for the second traffic phase when the second QoS requirement for the second traffic phase has been identified.
27. The first apparatus of claim 26, wherein the third identifying unit is configured to send a request to a User Equipment (UE) to activate the UE to identify the first traffic phase and the second traffic phase, receive a first feedback message from the UE indicating that the first traffic phase is identified, and identify the first QoS requirement for the first traffic phase according to the first feedback message;
wherein the second identifying unit is configured to receive a second feedback message from the UE indicating that the second traffic phase is identified, and identify the second QoS requirement for the second traffic phase according to the second feedback message.
28. A first device, characterized in that it has all the features of the first device of any of claims 15 to 27, and in that said first acquisition unit is configured to receive a message from a third device indicating said service type of said service.
29. A method for controlling quality of service (QoS) for a service, the service comprising a Guaranteed Bit Rate (GBR) service having at least a first service phase and a second service phase, the method comprising:
receiving, by a second device, first indication information from a first device, wherein the first indication information indicates a first QoS requirement for the first traffic phase, a second QoS requirement for the second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase;
the second equipment generates a QoS strategy according to the first indication information; and
the second device sends the QoS policy to a third device, the QoS policy for use by the third device to operate the traffic according to the first QoS requirements in the first traffic phase and to operate the traffic according to the second QoS requirements in the second traffic phase.
30. The method of claim 29, wherein the QoS policy indicates the first QoS requirement for the first traffic phase, the second QoS requirement for the second traffic phase, and the traffic phase flag identifying the first traffic phase and the second traffic phase, wherein the QoS policy is used by the third device to identify the first traffic phase and the second traffic phase according to the traffic phase flag indicated in the QoS policy.
31. The method of claim 29, wherein the generating a QoS policy according to the first indication information comprises:
the second device identifies the first traffic phase and the first QoS requirement for the first traffic phase according to the first indication information;
the second device generating a first QoS policy in accordance with the first QoS requirement for the first traffic phase, wherein the first QoS policy is for use by the third device to operate the traffic in accordance with the first QoS requirement in the first traffic phase;
the second device identifies the second traffic phase and the second QoS requirement for the second traffic phase according to the first indication information;
the second device generates a second QoS policy based on the second QoS requirements for the second traffic phase, wherein the second QoS policy is used by the third device to operate the traffic in the second traffic phase according to the second QoS requirements.
32. The method of any one of claims 29 to 31, wherein the third device comprises the first device.
33. A second apparatus for controlling quality of service (QoS) for a service, the service comprising a Guaranteed Bit Rate (GBR) service having at least a first service phase and a second service phase, the apparatus comprising:
a receiving unit, configured to receive first indication information from a first device, wherein the first indication information indicates a first QoS requirement for the first traffic phase, a second QoS requirement for the second traffic phase, and a traffic phase flag identifying the first traffic phase and the second traffic phase;
a generating unit, configured to generate a QoS policy according to the first indication information; and
a sending unit, configured to send the QoS policy to a third device, where the QoS policy is used by the third device to operate the service according to the first QoS requirement in the first service phase, and operate the service according to the second QoS requirement in the second service phase.
34. The second device of claim 33, wherein the QoS policy indicates the first QoS requirement for the first traffic phase, the second QoS requirement for the second traffic phase, and the traffic phase flag identifying the first traffic phase and the second traffic phase, wherein the QoS policy is used by the third device to identify the first traffic phase and the second traffic phase according to the traffic phase flag indicated in the QoS policy.
35. The second device of claim 33, further comprising:
an identifying unit, configured to identify the first traffic phase and the first QoS requirement for the first traffic phase according to the first indication information; wherein the generating unit is to generate a first QoS policy according to the first QoS requirement for the first traffic phase, the first QoS policy for use by the third device to operate the traffic according to the first QoS requirement in the first traffic phase; and wherein the generating unit is to generate a second QoS policy according to the second QoS requirement for the second traffic phase, the second QoS policy for use by the third device to operate the traffic according to the second QoS requirement in the second traffic phase.
36. A method for controlling quality of service (QoS) for a service, the service comprising a Guaranteed Bit Rate (GBR) service having at least a first service phase and a second service phase, the method comprising:
receiving, by a second device, a QoS policy from a first device, wherein the QoS policy indicates a first QoS requirement for the first traffic phase, a second QoS requirement for the second traffic phase, and the traffic phase flag identifying the first traffic phase and the second traffic phase;
the second device identifies the first traffic phase according to the traffic phase flag indicated in the QoS policy and identifies a first QoS requirement for the first traffic phase;
the second device operates the service according to the first QoS requirement in the first service stage according to the QoS strategy;
the second device identifying the second service phase according to the service phase flag indicated in the QoS policy and identifying a second QoS requirement for the second service phase;
and the second equipment operates the service according to the second QoS requirement in the second service stage according to the QoS strategy.
37. A second apparatus for controlling quality of service (QoS) for a service, the service comprising a Guaranteed Bit Rate (GBR) service having at least a first service phase and a second service phase, the apparatus comprising:
a receiving unit to receive a QoS policy from a first device, wherein the QoS policy indicates a first QoS requirement for the first traffic phase, a second QoS requirement for the second traffic phase, and the traffic phase flag to identify the first traffic phase and the second traffic phase;
an identifying unit, configured to identify the first service phase according to the service phase flag indicated in the QoS policy, and identify a first QoS requirement for the first service phase;
an operation unit, configured to operate the service according to the first QoS requirement in the first service phase according to the QoS policy;
wherein the identifying unit is further configured to identify the second traffic phase based on the traffic phase flag indicated in the QoS policy, and to identify a second QoS requirement for the second traffic phase, wherein the operating unit is further configured to operate the traffic in the second traffic phase according to the second QoS requirement based on the QoS policy.
38. A computer-readable storage medium, characterized in that it stores a computer program, which is executable by hardware to implement the method of any one of claims 1 to 14.
39. A computer-readable storage medium, characterized in that it stores a computer program, which, when executed by hardware, is capable of implementing the method of any one of claims 29 to 32.
40. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program, which is executable by hardware to implement the method of claim 36.
CN201480079810.9A 2014-06-16 2014-06-16 Method and apparatus for controlling QOS of service Active CN106465194B (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/CN2014/079953 WO2015192295A1 (en) 2014-06-16 2014-06-16 Method and device for controlling qos of a service

Publications (2)

Publication Number Publication Date
CN106465194A CN106465194A (en) 2017-02-22
CN106465194B true CN106465194B (en) 2020-01-21

Family

ID=54934654

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201480079810.9A Active CN106465194B (en) 2014-06-16 2014-06-16 Method and apparatus for controlling QOS of service

Country Status (2)

Country Link
CN (1) CN106465194B (en)
WO (1) WO2015192295A1 (en)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107734562B (en) * 2016-08-11 2020-04-03 华为技术有限公司 Service transmission control method, related equipment and communication system
EP3603220B1 (en) * 2017-03-24 2020-07-15 Telefonaktiebolaget LM Ericsson (publ) Qos flows inactivity counters
WO2019010697A1 (en) * 2017-07-14 2019-01-17 Telefonaktiebolaget Lm Ericsson (Publ) Method and apparatus for link adaptation in a mixed traffic environment
CN113329244B (en) * 2017-09-30 2022-07-22 华为技术有限公司 Service transmission method and device
CN109982391B (en) * 2017-12-28 2023-04-11 华为技术有限公司 Data processing method and device
CN112333828B (en) * 2020-11-18 2023-11-24 中国联合网络通信集团有限公司 Communication method, device and system
CN115474232A (en) * 2021-06-10 2022-12-13 维沃移动通信有限公司 QoS control method and device
CN115707038A (en) * 2021-08-17 2023-02-17 中兴通讯股份有限公司 Service processing method, base station and computer readable storage medium

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007068266A1 (en) * 2005-12-12 2007-06-21 Telefonaktiebolaget Lm Ericsson (Publ) Method and devices for specifying the quality of service in a transmission of data packets
EP2104275A1 (en) * 2008-03-21 2009-09-23 Research In Motion Limited Dynamic aggregated maximum bit rate for evolved packet system non-guaranteed bit rate quality of service enforcement and network bandwidth utilization
CN102883377A (en) * 2011-07-12 2013-01-16 中兴通讯股份有限公司 Service quality processing method and device
WO2014036338A2 (en) * 2012-08-31 2014-03-06 Qualcomm Incorporated Selective network parameter configuratons based on network identification of non-ims multimedia applications

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101128040A (en) * 2006-08-18 2008-02-20 华为技术有限公司 Wireless communication network and its service control method
US8542642B2 (en) * 2008-06-26 2013-09-24 Freescale Semiconductor, Inc. Channel condition dependent scheduling
US8285298B2 (en) * 2009-12-23 2012-10-09 At&T Mobility Ii Llc Chromatic scheduler for network traffic with disparate service requirements
CN102238743A (en) * 2010-05-05 2011-11-09 联芯科技有限公司 Multiplex bearer management method and device
CN102625377B (en) * 2011-01-31 2014-06-18 电信科学技术研究院 Method for establishing radio bearer, access point equipment, user equipment and system

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2007068266A1 (en) * 2005-12-12 2007-06-21 Telefonaktiebolaget Lm Ericsson (Publ) Method and devices for specifying the quality of service in a transmission of data packets
EP2104275A1 (en) * 2008-03-21 2009-09-23 Research In Motion Limited Dynamic aggregated maximum bit rate for evolved packet system non-guaranteed bit rate quality of service enforcement and network bandwidth utilization
CN102883377A (en) * 2011-07-12 2013-01-16 中兴通讯股份有限公司 Service quality processing method and device
WO2014036338A2 (en) * 2012-08-31 2014-03-06 Qualcomm Incorporated Selective network parameter configuratons based on network identification of non-ims multimedia applications

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
3GPP Organizational Partners.3GPP TS 23.203 V12.2.0-Technical Specification Group Services and System Aspects *
Policy and charging control architecture.《3GPP Technical Specification》.2013, *

Also Published As

Publication number Publication date
CN106465194A (en) 2017-02-22
WO2015192295A1 (en) 2015-12-23

Similar Documents

Publication Publication Date Title
CN106465194B (en) Method and apparatus for controlling QOS of service
CN110049517B (en) QoS flow control method and device
US9936534B2 (en) Method and apparatus for data transmission
EP2802170B1 (en) Method, system and device for service rate control
JP2021517799A (en) Communication method and communication device
EP3101944B1 (en) Facilitating in-bearer qos differentiation in multi-connectivity 5g networks
CN111630828B (en) Dynamic prioritization for live streaming
JP6518382B2 (en) Improved priority handling for data flow transport in communication systems
KR20140116450A (en) Method and apparatus for providing intelligent codec rate adaptation for wireless users
JP2013543346A (en) Basic equipment and method
CN111200565B (en) Information transmission method, terminal and network equipment
JP2016082438A (en) Communication control device, radio communication system, communication control method and radio base station
EP2478674A1 (en) NODE AND METHOD FOR QUALITY OF SERVICE (QoS) CONTROL
WO2019072397A1 (en) Scheduling of qos flows in a wireless communication system
KR20150135035A (en) Apparatus and method for improving service quality of media transmission through wlan
JP6047075B2 (en) Mobile gateway, control method thereof, and radio access network system including the same
KR101517383B1 (en) Method and apparatus for controlling buffer status report messaging
WO2023042044A1 (en) Control signaling between 3gpp network entities and transport network
Guo et al. Quality of service control
CN104054363B (en) A kind of method and apparatus of data stream transmitting
EP4274298A1 (en) Mechanism for setting time dependent quality of service
US10212722B2 (en) Volume-deadline scheduling
KR20170013673A (en) Method for controlling packet traffic and apparatus therefor
KR102022613B1 (en) Method and apparatus for controlling load of call traffic for mobile communication
WO2017049642A1 (en) Service processing method and apparatus

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
GR01 Patent grant
GR01 Patent grant