Communication method and related apparatus
The terminal device requests the network device to create a QoS flow that supports PDU Set processing, which solves the problem that the existing technology is difficult to meet the service quality requirements of XR services, and realizes efficient transmission and user experience improvement in network congestion scenarios.
Patent Information
- Application Number
- PCT/CN2024/110953
- Authority / Receiving Office
- WO · WO
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-08-11
- Filing Date
- 2024-08-09
- Publication Date
- 2025-02-20
AI Technical Summary
The prior art is difficult to meet the service quality needs of extended reality (XR) services, resulting in poor user experience.
By sending specific messages to network devices, the terminal device actively requests to create a quality of service flow (QoS flow) that supports processing based on packet data unit sets (PDU Sets) to meet the service quality needs of XR services.
By creating a QoS flow that supports PDU Set processing, it can ensure the transmission of important PDU Sets in the context of network congestion, and improve the service quality and user experience of XR services.
Smart Images

Figure CN2024110953_20022025_PF_FP_ABST
Abstract
Description
Communication method and related device
[0001] This application claims priority to the Chinese patent application filed with the State Intellectual Property Office of China on August 11, 2023, with application number 202311022712.9 and application name “Communication Methods and Related Devices”, the entire contents of which are incorporated by reference into this application. Technical Field
[0002] The present application relates to the field of communication technology, and in particular to a communication method and related devices. Background Art
[0003] In next-generation communication systems, a terminal device can establish at least one packet data unit (PDU) session with core network equipment through access network equipment. For each PDU session, at least one quality of service (QoS) flow can be established. Extended reality (XR) services are a key media application in 5G, requiring high throughput and high reliability.
[0004] To meet the quality of service requirements of XR services and enhance the XR user experience, the 3rd Generation Partnership Project (3GPP) has established a working group to study the characteristics of XR services and enhance XR service transmission technologies. Typically, XR services periodically generate data frames at a specific frame rate. For example, an augmented reality (AR) service with a 60fps frame rate generates 60 frames of video per second, with one frame appearing approximately every 16.66ms. The data for a single video frame may be carried and transmitted across multiple data packets. Generally speaking, only when all data packets of a frame are received within a specific latency or a specific percentage is received is it meaningful. Therefore, traditional transmission requirements based on packet granularity, such as latency and packet loss rate, have evolved into transmission requirements based on packet data unit sets (PDU Sets), namely, the PDU Set delay budget (PSDB) and PDU Set error rate (PSER). A PDU Set may refer to a set of data packets constituting a frame. If the video is encoded in a slice manner, a PDU Set may refer to a set of data packets constituting a slice.
[0005] Currently, for XR services, the QoS flow created for XR services may not meet users' service quality requirements or user experience for XR services. Therefore, how to meet users' service quality requirements for XR services has become an urgent problem to be solved.
[0006] Summary of the Invention
[0007] This application provides a communication method and related devices that can meet the service quality requirements of terminal devices for XR services, which is conducive to improving user experience.
[0008] In a first aspect, the present application provides a communication method performed by a terminal device, which may be the terminal device itself or a unit or module (such as a chip) in the terminal device with corresponding functions. In this method, the terminal device sends a first message to a network device, where the first message is used to create a first quality of service flow (QoS flow) for an extended reality (XR) service request, where the first QoS flow supports processing based on a packet data unit set (PDU Set);
[0009] The terminal device receives a second message from the network device, where the second message includes a first QoS parameter corresponding to the first QoS flow.
[0010] In an embodiment of the present application, a terminal device can proactively apply for / request the creation of a QoS flow for an XR service. After the network device completes the creation of the QoS flow for the XR service based on the terminal device's request, the network device can send the QoS parameters configured during the creation of the flow to the terminal device. This proactive request by the terminal device can meet the user's service quality requirements for XR services and improve the user experience.
[0011] In one possible design, before sending the first message to the network device, the method further includes:
[0012] The terminal device sends a PDU session establishment request to the network device;
[0013] The terminal device receives a PDU session establishment acceptance message from the network device;
[0014] The terminal device sends a first message to the network device, including:
[0015] Determining, according to the PDU session establishment accept message, whether the second QoS flow corresponding to the XR service supports PDU Set-based processing;
[0016] In a case where the second QoS flow does not support PDU Set-based processing, the first message is sent to the network device.
[0017] Under this implementation method, the terminal device can first determine whether the second QoS flow corresponding to the XR service created during the PDU session establishment process supports PDU Set-based processing. When it is determined that the second QoS flow does not support PDU Set-based processing, it sends a first message to the network device to request the creation of a first QoS flow that supports PDU Set-based processing. By creating a QoS flow based on PDU Set processing for the XR service, it can ensure that the network can transmit important PDU Sets in network congestion scenarios.
[0018] In one possible design, the PDU session establishment accept message includes first indication information and second indication information;
[0019] The first indication information indicates the second QoS flow;
[0020] The second indication information indicates whether the second QoS flow supports PDU Set-based processing.
[0021] In this implementation mode, the first indication information and the second indication information respectively indicate whether the second QoS flow and the second QoS flow support PDU Set-based processing. It is highly operational and allows the terminal device to prepare to determine whether the established second QoS flow supports PDU Set-based processing.
[0022] In one possible design, the terminal device sends a first message to the network device, including:
[0023] Acquire first information of the XR service, where the first information includes a second QoS parameter of the XR service, where the second QoS parameter includes one or more of the following information: a second PSDB, a second PSER, or a second PHISI;
[0024] The first message is sent to the network device according to the first information.
[0025] In this implementation, obtaining the first information of the XR service can be specifically understood as an application within the terminal device for providing the XR service opening QoS information to the terminal device. Therefore, the application can actively report the first information corresponding to the XR service to the upper layer (e.g., the application layer) of the terminal device, or the terminal device can periodically read the first information of the XR service provided by the application from the application within the terminal device. This implementation method of the application opening QoS information to the terminal device can obtain the QoS requirements of the XR service in real time, thereby promptly establishing a QoS flow that meets the QoS requirements.
[0026] In one possible design, the first message includes one or more of the following third QoS parameters expected by the terminal device:
[0027] a third PSDB, a third PSER, a third PHISI, or a first tag value;
[0028] The first marking value is used to indicate the processing of the PDU Set supporting the uplink direction and / or the downlink direction, and the third QoS parameter is determined based on the second QoS parameter.
[0029] In this implementation, the terminal device sends an expected first tag value to the network device, so that the network device can establish a QoS flow that supports processing of PDU Sets in the uplink direction and / or downlink direction according to the first tag value.
[0030] In one possible design, the first QoS parameter includes one or more of the following QoS parameters configured by the network device:
[0031] A first PSDB, a first PSER, a first PHISI, or a first tag value.
[0032] In this implementation, the network device sends the QoS parameters actually configured by the network device to the terminal device, which can be used to confirm the configuration of the network device. After the terminal device receives the first tag value sent by the network device, the terminal device can determine, based on the first tag value, whether the QoS flow established by the network device supports the processing of PDU Sets in the uplink direction and / or the downlink direction.
[0033] In one possible design, the terminal device sends a first message to the network device, including:
[0034] When the XR service is determined according to the traffic characteristics, the first message is sent to the network device.
[0035] In this implementation mode, the method of determining XR services based on traffic characteristics is more flexible and does not rely on the open capabilities of the network-side APP or the terminal's internal APP.
[0036] In one possible design, the first message includes one or more of the following third QoS parameters expected by the terminal device:
[0037] A first tag value, a second tag value, or a first 5QI; the first tag value is used to indicate support for PDU Set processing in the uplink direction and / or downlink direction, the second tag value is used to indicate that the first QoS flow supports PDU Set-based processing, the parameters indicated by the first 5QI include packet delay budget PDB and packet error rate PER, and the first 5QI is the 5QI associated with the second QoS flow.
[0038] In this implementation, the second tag value can be used by the network device to determine that the first Qos flow requested by the terminal device is processed based on the PDU Set. Therefore, the network device can process the PDB and PER indicated by the first 5QI as the PSDB and PSER expected by the terminal device. This implementation method of multiplexing the existing 5QI can save signaling overhead and is conducive to forward compatibility.
[0039] In one possible design, the first QoS parameter includes one or more of the following QoS parameters configured by the network device:
[0040] A first flag value, a second flag value, or a second 5QI.
[0041] In this implementation, the network device sends the QoS parameters actually configured on the network device to the terminal device, which can be used to confirm the configuration of the network device.
[0042] In one possible design, the first message is a PDU session modification request message, and / or the second message is a PDU session modification command message.
[0043] In this implementation, the first message is a PDU session modification request message, and the second message is a PDU session modification command message. This implementation method of enhancing existing messages can reduce the impact on the protocol and is conducive to forward compatibility of the protocol.
[0044] In one possible design, the first message includes flow information of the XR service.
[0045] In this implementation, the flow information of the XR service can be used by the network device to create the first QoS flow, which has strong operability.
[0046] In a second aspect, the present application provides a communication method performed by a terminal device, which may be the terminal device itself or a unit or module (such as a chip) in the terminal device with corresponding functions. In this method, the terminal device sends a third message to the network device, wherein the third message is used to request modification of a fourth QoS parameter corresponding to a third quality of service flow QoS flow created for an extended reality XR service; the third QoS flow supports processing based on a packet data unit set PDU Set;
[0047] The terminal device receives a fourth message from the network device, where the fourth message includes QoS parameter update information corresponding to the third QoS flow.
[0048] In an embodiment of the present application, the terminal device can proactively apply for / request to modify the QoS parameters corresponding to the QoS flow established for the XR service during the PDU session establishment process. After the network device completes the modification of the QoS parameters corresponding to the QoS flow of the XR service based on the request of the terminal device, the network device can send the QoS parameters reconfigured by the network device to the terminal device. This method of the terminal device proactively requesting to modify the QoS parameters can meet the user's service quality requirements for the XR service and is conducive to improving the user experience.
[0049] In one possible design, before the terminal device sends the third message to the network device, the method further includes:
[0050] The terminal device sends a PDU session establishment request to the network device;
[0051] The terminal device receives a PDU session establishment accept message from the network device, where the PDU session establishment accept message includes third indication information, and the third indication information indicates the third QoS flow.
[0052] In this implementation, the third QoS flow is indicated by the third indication information. The third indication information may be based on the existing packet filter information and identification information of the QoS flow. Reusing the existing information may reduce protocol changes.
[0053] In one possible design, the PDU session establishment accept message also includes a fourth QoS parameter, where the fourth QoS parameter includes one or more of the following information: a fourth PDU Set delay budget PSDB, a fourth PDU Set error rate PSER, fourth PDU Set integrated processing information PHISI, or a first tag value; the first tag value is used to indicate support for PDU Set processing in the uplink direction and / or the downlink direction;
[0054] The terminal device sending a third message to the network device includes:
[0055] Acquire a fifth QoS parameter of the XR service, where the fifth QoS parameter includes one or more of the following information: a fifth PSDB, a fifth PSER, or a fifth PHISI;
[0056] In a case where the fourth QoS parameter and the fifth QoS parameter do not match, the third message is sent to the network device based on the fifth QoS parameter.
[0057] In this implementation method, the mismatch between the fourth QoS parameter and the fifth QoS parameter can be understood as each item of the fourth QoS parameter and the fifth QoS parameter is different, or one or more items are different. Sending a third message to the network device based on the fifth QoS parameter can be understood as taking the fifth QoS parameter as the third QoS parameter expected by the terminal device, and carrying it in the third message and sending it to the network device.
[0058] In one possible design, the PDU session establishment accept message also includes a fourth QoS parameter, where the fourth QoS parameter includes one or more of the following information: a fourth PSDB, a fourth PSER, a fourth PHISI, or a first tag value; the first tag value is used to indicate support for processing of the PDU Set in the uplink direction and / or the downlink direction;
[0059] The terminal device sending a third message to the network device includes:
[0060] When the number of PDU Sets of the XR service received per unit time is less than a first threshold, the third message is sent to the network device based on the fourth QoS parameter.
[0061] In this implementation, if the number of XR service PDU Sets received per unit time is less than the first threshold, it means that the XR service user experience is poor. Therefore, the terminal device can request the network device to modify the QoS parameters to meet user needs. Here, sending the third message to the network device based on the fourth QoS parameter can be understood as adjusting one or more of the fourth PSDB, fourth PSER, or fourth PHISI included in the fourth QoS parameter, and sending the corresponding adjusted parameters as the third PSDB, third PSER, or third PHISI carried in the third QoS parameter to the network device, which is highly operational and flexible.
[0062] In one possible design, the third message includes one or more of the following third QoS parameters expected by the terminal device:
[0063] a third PSDB, a third PSER, or a third PHISI;
[0064] The third QoS parameter is determined based on the fourth QoS parameter, or the third QoS parameter is determined based on the fifth QoS parameter.
[0065] The method of requesting to establish a QoS flow by carrying the third QoS flow parameter in the third message is similar to the existing mechanism and is easy to implement. In one possible design, the QoS parameter update information includes one or more of the following sixth QoS parameters reconfigured by the network device:
[0066] A sixth PSDB, a sixth PSER, or a sixth PHISI.
[0067] In this implementation, the network device sends the reconfigured QoS parameters to the terminal device, which can be used to confirm the configuration of the network device. At the same time, it is convenient for the terminal device to perceive the parameters of the current QoS flow so that it can initiate modification if it finds that the QoS requirements are not met.
[0068] In one possible design, the PDU session establishment accept message also includes a fourth QoS parameter, where the fourth QoS parameter includes one or more of the following information: a fourth 5QI, a first tag value, or a third tag value; the first tag value is used to indicate support for uplink and / or downlink PDU Set processing, and the third tag value is used to indicate that the third QoS flow supports PDU Set-based processing;
[0069] The terminal device sending a third message to the network device includes:
[0070] Acquire a fifth QoS parameter of the XR service, where the fifth QoS parameter includes a fifth 5QI;
[0071] In a case where the fourth 5QI and the fifth 5QI do not match, the third message is sent to the network device based on the fifth 5QI.
[0072] In this implementation, the terminal device obtains the fifth QoS parameter of the XR service, which can be understood as follows: the application inside the terminal device for providing the XR service can open the QoS information to the terminal device, so the application can actively report the fifth QoS parameter corresponding to the XR service to the upper layer of the terminal device (such as the application layer), or the terminal device can periodically read the fifth QoS parameter of the XR service provided by the application from the application inside the terminal device. The mismatch between the fourth 5QI and the fifth 5QI can be understood as the PDB or PER indicated by the fourth 5QI is different from the PDB or PER indicated by the fifth 5QI. Sending a third message to the network device based on the fifth 5QI can be understood as carrying the fifth 5QI in the third message and sending it to the network device, that is, the fifth 5QI is used as the third 5QI expected by the terminal device.
[0073] In one possible design, the PDU session establishment accept message also includes a fourth QoS parameter, where the fourth QoS parameter includes one or more of the following information: a fourth 5QI, a first tag value, or a third tag value; the first tag value is used to indicate support for uplink and / or downlink PDU Set processing, and the third tag value is used to indicate that the third QoS flow supports PDU Set-based processing;
[0074] The terminal device sending a third message to the network device includes:
[0075] When the number of PDU Sets of the XR service received in a unit time is less than a first threshold, the third message is sent to the network device based on the fourth 5QI.
[0076] In this implementation, if the number of PDU Sets of XR services received per unit time is less than the first threshold, it means that the XR service user experience is poor. Therefore, the terminal device can request the network device to modify the QoS parameters to meet user needs. Here, sending the third message to the network device based on the fourth QoS parameter can be understood as adjusting the PDB or PER indicated by the fourth 5QI, and sending the corresponding adjusted parameters as the third 5QI to the network device, which has strong operability.
[0077] In one possible design, the third message includes one or more of the following third QoS parameters expected by the terminal device:
[0078] a third 5QI, or a third tag value;
[0079] The third 5QI is determined based on the fourth 5QI parameter, or the third QoS parameter is determined based on the fifth 5QI.
[0080] In this implementation, the network device can determine that the PDB or PER indicated by the third 5QI is actually PSDB or PSER in combination with the third tag value, which can save signaling overhead.
[0081] In one possible design, the QoS parameter update information includes one or more of the following sixth QoS parameters reconfigured by the network device:
[0082] Sixth 5QI, or third marker value.
[0083] In this implementation, the network device sends the reconfigured QoS parameters to the terminal device, which can be used to confirm the configuration of the network device. At the same time, it is convenient for the terminal device to perceive the parameters of the current QoS flow so that it can initiate modification if it finds that the QoS requirements are not met.
[0084] In one possible design, the third message is a PDU session modification request message, and / or the fourth message is a PDU session modification command message.
[0085] In this implementation, the third message is a PDU session modification request message, and the fourth message is a PDU session modification command message. This implementation method of enhancing existing messages can reduce the impact on the protocol and is conducive to forward compatibility of the protocol.
[0086] In a third aspect, the present application provides a communication method performed by a network device, which may be the network device itself or a unit or module (e.g., a chip) in the network device with corresponding functions. In this method, the network device receives a first message from a terminal device, where the first message is used to create a first quality of service (QoS) flow for an extended reality (XR) service request, where the first QoS flow supports processing based on a packet data unit set (PDU Set);
[0087] The network device sends a second message to the terminal device, where the second message includes a first QoS parameter corresponding to the first QoS flow.
[0088] In one possible design, before receiving the first message from the terminal device, the method further includes:
[0089] The network device receives a PDU session establishment request from the terminal device;
[0090] The network device sends a PDU session establishment accept message to the terminal device; the PDU session establishment accept message is used to indicate whether the second QoS flow corresponding to the XR service supports PDU Set-based processing.
[0091] In one possible design, the PDU session establishment accept message includes first indication information and second indication information;
[0092] The first indication information indicates the second QoS flow;
[0093] The second indication information indicates whether the second QoS flow supports PDU Set-based processing.
[0094] In one possible design, the first message includes one or more of the following third QoS parameters expected by the terminal device:
[0095] a third PSDB, a third PSER, a third PHISI, or a first tag value;
[0096] The first flag value is used to indicate support for processing of the PDU Set in the uplink direction and / or the downlink direction.
[0097] In one possible design, the first QoS parameter includes one or more of the following QoS parameters configured by the network device:
[0098] A first PSDB, a first PSER, a first PHISI, or a first tag value.
[0099] In one possible design, the first message includes one or more of the following third QoS parameters expected by the terminal device:
[0100] A first tag value, a second tag value, or a first 5QI; the first tag value is used to indicate support for PDU Set processing in the uplink direction and / or downlink direction, the second tag value is used to indicate that the first QoS flow supports PDU Set-based processing, the parameters indicated by the first 5QI include packet delay budget PDB and packet error rate PER, and the first 5QI is the 5QI associated with the second QoS flow.
[0101] In one possible design, the first QoS parameter includes one or more of the following QoS parameters configured by the network device:
[0102] A first flag value, a second flag value, or a second 5QI.
[0103] In one possible design, the first message is a PDU session modification request message, and / or the second message is a PDU session modification command message.
[0104] In one possible design, the first message includes flow information of the XR service.
[0105] In a fourth aspect, the present application provides a communication method performed by a network device, which may be the network device itself or a unit or module (such as a chip) in the network device with corresponding functions. In this method, the network device receives a third message from a terminal device, wherein the third message is used to request modification of a fourth QoS parameter corresponding to a third quality of service flow QoS flow created for an extended reality XR service; the third QoS flow supports processing based on a packet data unit set PDU Set;
[0106] The network device sends a fourth message to the terminal device, where the fourth message includes QoS parameter update information corresponding to the third QoS flow.
[0107] In one possible design, before the network device receives the third message from the terminal device, the method further includes:
[0108] The network device receives a PDU session establishment request from the terminal device;
[0109] The network device sends a PDU session establishment accept message to the terminal device, where the PDU session establishment accept message includes third indication information, and the third indication information indicates the third QoS flow.
[0110] In one possible design, the third message includes one or more of the following third QoS parameters expected by the terminal device:
[0111] A third PSDB, a third PSER, or a third PHISI.
[0112] In one possible design, the QoS parameter update information includes one or more of the following sixth QoS parameters reconfigured by the network device:
[0113] A sixth PSDB, a sixth PSER, or a sixth PHISI.
[0114] In one possible design, the third message includes one or more of the following third QoS parameters expected by the terminal device:
[0115] A third 5QI, or a third flag value.
[0116] In one possible design, the QoS parameter update information includes one or more of the following sixth QoS parameters reconfigured by the network device:
[0117] Sixth 5QI, or third marker value.
[0118] In one possible design, the third message is a PDU session modification request message, and / or the fourth message is a PDU session modification command message.
[0119] In a fifth aspect, the present application provides a communication device, which may be the communication device itself, or a module, chip, or unit in the communication device. For example, the communication device may be a terminal device. The communication device includes:
[0120] a transceiver unit, configured to send a first message to a network device, where the first message is used to create a first quality of service flow (QoS flow) for an extended reality (XR) service request, where the first QoS flow supports processing based on a packet data unit set (PDU Set);
[0121] The transceiver unit is configured to receive a second message from the network device, where the second message includes a first QoS parameter corresponding to the first QoS flow.
[0122] In one possible design, before sending the first message to the network device, the transceiver unit is configured to:
[0123] Sending a PDU session establishment request to the network device;
[0124] Receiving a PDU session establishment accept message from the network device;
[0125] The communication device further comprises a processing unit, wherein:
[0126] The processing unit is configured to determine, according to the PDU session establishment accept message, whether the second QoS flow corresponding to the XR service supports PDU Set-based processing;
[0127] The transceiver unit is configured to send the first message to the network device when the second QoS flow does not support PDU Set-based processing.
[0128] In one possible design, the PDU session establishment accept message includes first indication information and second indication information;
[0129] The first indication information indicates the second QoS flow;
[0130] The second indication information indicates whether the second QoS flow supports PDU Set-based processing.
[0131] In one possible design, when sending the first message to the network device, the processing unit is configured to obtain first information of the XR service, where the first information includes a second QoS parameter of the XR service, where the second QoS parameter includes one or more of the following information: a second PSDB, a second PSER, or a second PHISI;
[0132] The transceiver unit is configured to send the first message to the network device according to the first information.
[0133] In one possible design, the first message includes one or more of the following third QoS parameters expected by the terminal device:
[0134] a third PSDB, a third PSER, a third PHISI, or a first tag value;
[0135] The first marking value is used to indicate the processing of the PDU Set supporting the uplink direction and / or the downlink direction, and the third QoS parameter is determined based on the second QoS parameter.
[0136] In one possible design, the first QoS parameter includes one or more of the following QoS parameters configured by the network device:
[0137] A first PSDB, a first PSER, a first PHISI, or a first tag value.
[0138] In one possible design, when sending the first message to the network device, the transceiver unit is configured to:
[0139] When the XR service is determined according to the traffic characteristics, the first message is sent to the network device.
[0140] In one possible design, the first message includes one or more of the following third QoS parameters expected by the terminal device:
[0141] A first tag value, a second tag value, or a first 5QI; the first tag value is used to indicate support for PDU Set processing in the uplink direction and / or downlink direction, the second tag value is used to indicate that the first QoS flow supports PDU Set-based processing, the parameters indicated by the first 5QI include packet delay budget PDB and packet error rate PER, and the first 5QI is the 5QI associated with the second QoS flow.
[0142] In one possible design, the first QoS parameter includes one or more of the following QoS parameters configured by the network device:
[0143] A first flag value, a second flag value, or a second 5QI.
[0144] In one possible design, the first message is a PDU session modification request message, and / or the second message is a PDU session modification command message.
[0145] In one possible design, the first message includes flow information of the XR service.
[0146] In a sixth aspect, the present application provides a communication device, which may be the communication device itself, or a module, chip, or unit in the communication device. For example, the communication device may be a terminal device. The communication device includes:
[0147] a transceiver unit, configured to send a third message to the network device, wherein the third message is used to request modification of a fourth QoS parameter corresponding to a third quality of service flow QoS flow created for the extended reality XR service; wherein the third QoS flow supports processing based on a packet data unit set PDU Set;
[0148] The transceiver unit is configured to receive a fourth message from the network device, where the fourth message includes QoS parameter update information corresponding to the third QoS flow.
[0149] In one possible design, before sending the third message to the network device, the transceiver unit is configured to:
[0150] Sending a PDU session establishment request to the network device;
[0151] A PDU session establishment accept message is received from the network device, where the PDU session establishment accept message includes third indication information, and the third indication information indicates the third QoS flow.
[0152] In one possible design, the PDU session establishment accept message also includes a fourth QoS parameter, where the fourth QoS parameter includes one or more of the following information: a fourth PDU Set delay budget PSDB, a fourth PDU Set error rate PSER, fourth PDU Set integrated processing information PHISI, or a first tag value; the first tag value is used to indicate support for PDU Set processing in the uplink direction and / or the downlink direction;
[0153] When sending the third message to the network device, the transceiver unit is configured to:
[0154] Acquire a fifth QoS parameter of the XR service, where the fifth QoS parameter includes one or more of the following information: a fifth PSDB, a fifth PSER, or a fifth PHISI;
[0155] In a case where the fourth QoS parameter and the fifth QoS parameter do not match, the third message is sent to the network device based on the fifth QoS parameter.
[0156] In one possible design, the PDU session establishment accept message also includes a fourth QoS parameter, where the fourth QoS parameter includes one or more of the following information: a fourth PSDB, a fourth PSER, a fourth PHISI, or a first tag value; the first tag value is used to indicate support for processing of the PDU Set in the uplink direction and / or the downlink direction;
[0157] When sending the third message to the network device, the transceiver unit is configured to:
[0158] When the number of PDU Sets of the XR service received per unit time is less than a first threshold, the third message is sent to the network device based on the fourth QoS parameter.
[0159] In one possible design, the third message includes one or more of the following third QoS parameters expected by the terminal device:
[0160] a third PSDB, a third PSER, or a third PHISI;
[0161] The third QoS parameter is determined based on the fourth QoS parameter, or the third QoS parameter is determined based on the fifth QoS parameter.
[0162] In one possible design, the QoS parameter update information includes one or more of the following sixth QoS parameters reconfigured by the network device:
[0163] A sixth PSDB, a sixth PSER, or a sixth PHISI.
[0164] In one possible design, the PDU session establishment accept message also includes a fourth QoS parameter, where the fourth QoS parameter includes one or more of the following information: a fourth 5QI, a first tag value, or a third tag value; the first tag value is used to indicate support for uplink and / or downlink PDU Set processing, and the third tag value is used to indicate that the third QoS flow supports PDU Set-based processing;
[0165] When sending the third message to the network device, the transceiver unit is configured to:
[0166] Acquire a fifth QoS parameter of the XR service, where the fifth QoS parameter includes a fifth 5QI;
[0167] In a case where the fourth 5QI and the fifth 5QI do not match, the third message is sent to the network device based on the fifth 5QI.
[0168] In one possible design, the PDU session establishment accept message also includes a fourth QoS parameter, where the fourth QoS parameter includes one or more of the following information: a fourth 5QI, a first tag value, or a third tag value; the first tag value is used to indicate support for uplink and / or downlink PDU Set processing, and the third tag value is used to indicate that the third QoS flow supports PDU Set-based processing;
[0169] When sending the third message to the network device, the transceiver unit is configured to:
[0170] When the number of PDU Sets of the XR service received in a unit time is less than a first threshold, the third message is sent to the network device based on the fourth 5QI.
[0171] In one possible design, the third message includes one or more of the following third QoS parameters expected by the terminal device:
[0172] a third 5QI, or a third tag value;
[0173] The third 5QI is determined based on the fourth 5QI parameter, or the third QoS parameter is determined based on the fifth 5QI.
[0174] In one possible design, the QoS parameter update information includes one or more of the following sixth QoS parameters reconfigured by the network device:
[0175] Sixth 5QI, or third marker value.
[0176] In one possible design, the third message is a PDU session modification request message, and / or the fourth message is a PDU session modification command message.
[0177] In a seventh aspect, the present application provides a communication device, which may be the communication device itself, or a module, chip, or unit in the communication device. Exemplarily, the communication device may be a network device, such as an SMF. The communication device includes:
[0178] a transceiver unit, configured to receive a first message from a terminal device, where the first message is used to create a first quality of service flow (QoS flow) for an extended reality (XR) service request, where the first QoS flow supports processing based on a packet data unit set (PDU Set);
[0179] The transceiver unit is used to send a second message to the terminal device, where the second message includes a first QoS parameter corresponding to the first QoS flow.
[0180] In one possible design, before receiving the first message from the terminal device, the transceiver unit is configured to:
[0181] Receiving a PDU session establishment request from the terminal device;
[0182] Send a PDU session establishment accept message to the terminal device; the PDU session establishment accept message is used to determine whether the second QoS flow corresponding to the XR service supports PDU Set-based processing.
[0183] In one possible design, the PDU session establishment accept message includes first indication information and second indication information;
[0184] The first indication information indicates the second QoS flow;
[0185] The second indication information indicates whether the second QoS flow supports PDU Set-based processing.
[0186] In one possible design, the first message includes one or more of the following third QoS parameters expected by the terminal device:
[0187] a third PSDB, a third PSER, a third PHISI, or a first tag value;
[0188] The first flag value is used to indicate support for processing of the PDU Set in the uplink direction and / or the downlink direction.
[0189] In one possible design, the first QoS parameter includes one or more of the following QoS parameters configured by the network device:
[0190] A first PSDB, a first PSER, a first PHISI, or a first tag value.
[0191] In one possible design, the first message includes one or more of the following third QoS parameters expected by the terminal device:
[0192] A first tag value, a second tag value, or a first 5QI; the first tag value is used to indicate support for PDU Set processing in the uplink direction and / or downlink direction, the second tag value is used to indicate that the first QoS flow supports PDU Set-based processing, the parameters indicated by the first 5QI include packet delay budget PDB and packet error rate PER, and the first 5QI is the 5QI associated with the second QoS flow.
[0193] In one possible design, the first QoS parameter includes one or more of the following QoS parameters configured by the network device:
[0194] A first flag value, a second flag value, or a second 5QI.
[0195] In one possible design, the first message is a PDU session modification request message, and / or the second message is a PDU session modification command message.
[0196] In one possible design, the first message includes flow information of the XR service.
[0197] In an eighth aspect, the present application provides a communication device, which may be the communication device itself, or a module, chip, or unit in the communication device. For example, the communication device may be a network device, such as an SMF. The communication device includes:
[0198] a transceiver unit, configured to receive a third message from a terminal device, the third message being used to request modification of a fourth QoS parameter corresponding to a third quality of service flow QoS flow created for an extended reality (XR) service; the third QoS flow supporting processing based on a packet data unit set (PDU Set);
[0199] The transceiver unit is used to send a fourth message to the terminal device, where the fourth message includes QoS parameter update information corresponding to the third QoS flow.
[0200] In one possible design, before receiving the third message from the terminal device, the transceiver unit is configured to:
[0201] Receiving a PDU session establishment request from the terminal device;
[0202] A PDU session establishment accept message is sent to the terminal device, where the PDU session establishment accept message includes third indication information, and the third indication information indicates the third QoS flow.
[0203] In one possible design, the third message includes one or more of the following third QoS parameters expected by the terminal device:
[0204] A third PSDB, a third PSER, or a third PHISI.
[0205] In one possible design, the QoS parameter update information includes one or more of the following sixth QoS parameters reconfigured by the network device:
[0206] A sixth PSDB, a sixth PSER, or a sixth PHISI.
[0207] In one possible design, the third message includes one or more of the following third QoS parameters expected by the terminal device:
[0208] A third 5QI, or a third flag value.
[0209] In one possible design, the QoS parameter update information includes one or more of the following sixth QoS parameters reconfigured by the network device:
[0210] Sixth 5QI, or third marker value.
[0211] In one possible design, the third message is a PDU session modification request message, and / or the fourth message is a PDU session modification command message.
[0212] In a ninth aspect, the present application provides a communication device, which includes a processor, and the processor is used to execute a computer program so that the communication device executes any method as described in any one of the first to fourth aspects.
[0213] In one possible design, the communication device may be a chip that implements the method of any one of the first to fourth aspects or a device including a chip.
[0214] In one possible design, the communication device further includes a transceiver, and the processor is coupled to the transceiver.
[0215] In one possible design, the communication device further includes a memory. A processor is coupled to the memory, the memory stores a computer program, and the processor is further configured to call the computer program in the memory. Alternatively, the processor and memory may be integrated.
[0216] In the tenth aspect, the present application provides a communication device, which includes a processor and an interface circuit, the interface circuit being used to receive signals from other communication devices outside the communication device and transmit them to the processor or send signals from the processor to other communication devices outside the communication device, and the processor being used to implement any method as described in any one of the first to fourth aspects through a logic circuit or executing code instructions.
[0217] In the eleventh aspect, the present application provides a computer-readable storage medium, which stores a computer program or instruction. When the computer program or instruction is executed by a computer, it implements the method described in any one of the first to fourth aspects.
[0218] In a twelfth aspect, the present application provides a computer program product. When a computer reads and executes the computer program product, the computer executes any one of the methods described in any one of the first to fourth aspects.
[0219] In a thirteenth aspect, the present application provides a communication system, which includes a communication device for implementing the method described in any one of the first aspects above, and a communication device for implementing the method described in any one of the second aspects above.
[0220] The beneficial effects of the third to thirteenth aspects can refer to the beneficial effects of the first aspect and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS
[0221] FIG1 is a schematic diagram of the architecture of the communication system used in this application;
[0222] FIG2 is a QoS model based on QoS flow provided by this application;
[0223] FIG3 is a schematic diagram of a process for establishing a QoS flow provided by the present application;
[0224] FIG4 is a schematic diagram of a bidirectional QoS flow provided in an embodiment of the present application;
[0225] FIG5 is a schematic diagram of an interaction flow of a communication method provided in an embodiment of the present application;
[0226] FIG6 is another interactive flow diagram of the communication method provided in an embodiment of the present application;
[0227] FIG7 is a schematic structural diagram of a communication device provided in an embodiment of the present application;
[0228] FIG8 is a schematic structural diagram of another communication device provided in an embodiment of the present application;
[0229] FIG9 is a schematic structural diagram of another communication device provided in an embodiment of the present application. DETAILED DESCRIPTION
[0230] The specific embodiments of the present application are further described in detail below with reference to the accompanying drawings.
[0231] The terms "first" and "second" and the like in the specification, claims, and drawings of this application are used to distinguish between different objects, not to describe a particular order. Furthermore, the terms "including" and "having," and any variations thereof, are intended to cover non-exclusive inclusions. For example, a process, method, system, product, or apparatus comprising a series of steps or elements is not limited to the listed steps or elements, but may optionally include steps or elements not listed, or may optionally include other steps or elements inherent to the process, method, product, or apparatus.
[0232] References herein to "embodiments" mean that a particular feature, structure, or characteristic described in connection with the embodiments may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it constitute an independent or alternative embodiment that is mutually exclusive of other embodiments. It is understood, both explicitly and implicitly, by those skilled in the art that the embodiments described herein may be combined with other embodiments.
[0233] In this application, "at least one (item)" refers to one or more, "more than one" refers to two or more, "at least two (items)" refers to two or three and more than three, and "and / or" is used to describe the association relationship of associated objects, indicating that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and A and B exist at the same time, where A and B can be singular or plural. The character " / " generally indicates that the previous and next associated objects are in an "or" relationship. "At least one of the following items" or similar expressions refers to any combination of these items, including any combination of single items or plural items. For example, at least one of a, b or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, c can be single or multiple.
[0234] To better understand the embodiments of the present application, the following first introduces the system architecture involved in the embodiments of the present application:
[0235] Please refer to Figure 1, which is a schematic diagram of the architecture of the communication system used in this application. As shown in Figure 1, the communication system 1000 includes a radio access network (RAN) 100 and a core network (CN) 200. Optionally, the communication system 1000 may also include the Internet 300, which may also be called a data network (DN). Its main function is to provide specific data services, such as operator services, Internet access, or third-party services. The RAN 100 includes at least one RAN node (such as 110a and 110b in Figure 1, collectively referred to as 110) and at least one terminal (such as 120a-120j in Figure 1, collectively referred to as 120). The RAN 100 may also include other RAN nodes, such as wireless relay equipment and / or wireless backhaul equipment (not shown in Figure 1). The terminal 120 is connected to the RAN node 110 via a wireless connection. The RAN node 110 is connected to the core network 200 via a wireless or wired connection. The core network device in the core network 200 and the RAN node 110 in the RAN 100 may be different physical devices, or may be the same physical device that integrates core network logical functions and radio access network logical functions.
[0236] The RAN 100 may be a cellular system related to the Third Generation Partnership Project (3GPP), such as a 4G or 5G mobile communication system, or a future-oriented evolutionary system (such as a 6G mobile communication system). The RAN 100 may also be an open access network (O-RAN or ORAN), a cloud radio access network (CRAN), or a wireless fidelity (WiFi) system. The RAN 100 may also be a communication system that integrates two or more of the above systems.
[0237] RAN node 110, sometimes also referred to as access network equipment, RAN entity, or access node, constitutes part of the communication system and facilitates wireless access for terminals. Multiple RAN nodes 110 in communication system 1000 can be of the same type or different types. In some scenarios, the roles of RAN node 110 and terminal 120 are relative. For example, network element 120i in Figure 1 can be a helicopter or drone, which can be configured as a mobile base station. For terminal 120j accessing RAN 100 via network element 120i, network element 120i is a base station; however, for base station 110a, network element 120i is a terminal. RAN node 110 and terminal 120 are sometimes referred to as communication devices. For example, base stations 110a and 110b in Figure 1 can be understood as communication devices with base station functionality, and terminals 120a-120j can be understood as communication devices with terminal functionality.
[0238] In one possible scenario, a RAN node may be a base station, an evolved NodeB (eNodeB), an access point (AP), a transmission reception point (TRP), a next generation NodeB (gNB), a next generation base station in a sixth generation (6G) mobile communication system, a base station in a future mobile communication system, or an access node in a WiFi system. A RAN node may be a macro base station (such as 110a in FIG1 ), a micro base station or an indoor station (such as 110b in FIG1 ), a relay node or a donor node, or a wireless controller in a CRAN scenario. Optionally, a RAN node may also be a server, a wearable device, a vehicle or an onboard device. For example, an access network device in vehicle to everything (V2X) technology may be a road side unit (RSU). All or part of the functions of the RAN node in this application may also be implemented by software functions running on hardware, or by virtualized functions instantiated on a platform (such as a cloud platform). The RAN node in this application may also be a logical node, a logical module or software that can implement all or part of the RAN node functions.
[0239] In another possible scenario, multiple RAN nodes collaborate to assist terminals in achieving wireless access, with different RAN nodes implementing portions of the base station's functions. For example, a RAN node can be a centralized unit (CU), a distributed unit (DU), a CU-control plane (CP), a CU-user plane (UP), or a radio unit (RU). The CU implements the base station's radio resource control protocol and packet data convergence protocol (PDCP) functions, as well as the service data adaptation protocol (SDAP) functions. The DU implements the base station's radio link control layer and medium access control (MAC) layer functions, as well as some or all of the physical layer functions. For detailed descriptions of each of these protocol layers, please refer to the relevant technical specifications of the 3rd Generation Partnership Project (3GPP). The CU and DU can be separate or included in the same network element, such as the baseband unit (BBU). The RU may be included in a radio frequency device or a radio frequency unit, for example, in a remote radio unit (RRU), an active antenna unit (AAU) or a remote radio head (RRH).
[0240] Optionally, the RAN node may be expressed differently, such as an access network device. Unless otherwise specified in this application, the access network device is used for expression.
[0241] In different systems, CU (or CU-CP and CU-UP), DU or RU may also have different names, but those skilled in the art can understand their meanings. For example, in the ORAN system, CU may also be called O-CU (Open CU), DU may also be called O-DU, CU-CP may also be called O-CU-CP, CU-UP may also be called O-CU-UP, and RU may also be called O-RU. For the convenience of description, this application uses CU, CU-CP, CU-UP, DU and RU as examples for description. Any unit of CU (or CU-CP, CU-UP), DU and RU in this application can be implemented by a software module, a hardware module, or a combination of a software module and a hardware module.
[0242] A terminal may also be referred to as a terminal device, user equipment (UE), mobile station, mobile terminal, mobile equipment (ME), etc. The terminal can be widely used in various scenarios, such as device-to-device (D2D), vehicle-to-everything (V2X) communication, machine-type communication (MTC), Internet of Things (IOT), virtual reality, augmented reality, industrial control, autonomous driving, telemedicine, smart grid, smart furniture, smart office, smart wearable, smart transportation, smart city, etc. The terminal can be a mobile phone, tablet computer, computer with wireless transceiver function, wearable device, vehicle, drone, helicopter, airplane, ship, robot, robotic arm, smart home device, etc. The embodiments of the present application do not limit the device form of the terminal.
[0243] The core network may include one or more functional entities (also called core network elements, network elements, entities, etc.), such as policy control function (PCF), access and mobility management function (AMF), session management function (SMF), application function (AF), and user plane function (UPF).
[0244] The following is an introduction to the functions of each device:
[0245] The access and mobility management function (also referred to as access and mobility management equipment, access and mobility management function entity, access and mobility management function network element, mobile management equipment, access management equipment, mobile management network element, mobile management entity or AMF, etc.) is a type of core network equipment. The device can be used to manage the access control and mobility of the user equipment. In actual applications, it includes the access and mobility management function in the mobility management entity (MME) in the network framework in long term evolution (LTE), and adds access management functions. Specifically, it can be responsible for the registration, mobility management, tracking area update process, reachability detection, selection of session management network element, mobile state transition management, etc. of the user equipment. For example, in 5G, the access and mobility management network element can be an AMF network element. In future communications, such as 6G, the access and mobility management network element can still be an AMF network element, or have other names, which are not limited in this application. When the access and mobility management network element is an AMF network element, the AMF can provide Namf services.
[0246] The user plane function (also known as user plane equipment or UPF) is a type of core network equipment. This equipment is responsible for forwarding and receiving user data from user devices. It receives user data from the data network and transmits it to the user device via access network elements. The user plane function network element also receives user data from the user device via access network elements and forwards it to the data network. The transmission resources and scheduling functions provided by the user plane function network element to the user device are managed and controlled by the session management function network element.
[0247] The session management function (also known as session management device or SMF, etc.) is a type of core network device. This device can be used to be responsible for the session management of the user equipment (including session establishment, modification and release), selection and reselection of user plane function network elements, Internet protocol (IP) address allocation of the user equipment, quality of service (QoS) control, etc. For example, in 5G, the session management network element can be a session management function (SMF) network element. In future communication systems, such as 6G, the session management network element can still be an SMF network element, or have other names, which are not limited in this application. When the session management network element is an SMF network element, the SMF can provide Nsmf services.
[0248] The policy control function (also known as policy control network element, policy control function network element, policy control device, policy control function entity, PCF, etc.) is mainly responsible for providing a unified policy framework for network behavior management, providing policy rules for control plane functions, and obtaining registration information related to policy decisions.
[0249] The application function (also known as application function network element, application function device, application function entity, AF, etc.) can be either a third-party application control platform or a device deployed by an operator. Its main functions include providing application-related information and providing services for multiple application servers.
[0250] It should be noted that in actual deployment, different functions or network elements can be co-located. For example, the access and mobility management network element can be co-located with the session management network element; and the session management network element can be co-located with the user plane network element. When two network elements are co-located, the interaction between the two network elements provided in the embodiments of the present application becomes an internal operation of the co-located network element or can be omitted.
[0251] It should be noted that the above functional entity is merely a name and does not limit the entity. For example, the session management function could be replaced by "session management function entity" or another name. Furthermore, the session management function entity could correspond to an entity that includes other functions in addition to the session management function. The user plane function could also be replaced by "user plane function entity" or another name, and the user plane function entity could also correspond to an entity that includes other functions in addition to the user plane function. This is explained here in a unified manner and will not be repeated below.
[0252] It should be noted that the message names between network elements or the names of parameters in the messages in the following embodiments of the present application are only examples, and other names may be used in specific implementations. The embodiments of the present application do not make specific limitations on this.
[0253] In this application, "sending information to...(terminal)" can be understood as the destination of the information being the terminal. This can include sending information to the terminal directly or indirectly. "Receiving information from...(terminal)" can be understood as the source of the information being the terminal, which can include receiving information from the terminal directly or indirectly. The information may undergo necessary processing between the source and destination of the information, such as format changes, but the destination can understand the valid information from the source. Similar expressions in this application can be understood similarly and will not be repeated here.
[0254] It should be understood that the terminal device in the embodiments of the present application can be any of the above-mentioned devices or chips, and the specific details are not limited here. Whether as a device or a chip, the terminal device can be manufactured, sold, or used as an independent product. In this embodiment and subsequent embodiments, only the terminal device is used as an example.
[0255] It should be understood that the device used to implement the function of the network device in the embodiments of the present application can be the network device itself, or it can be a device that can support the network device to implement the function, such as a chip system or a combination device or component that can implement the function of the network device, and the device can be installed in the network device. In the embodiments of the present application, the chip system can be composed of chips, or it can include chips and other discrete devices. In this embodiment and subsequent embodiments, only the network device is used as an example for description.
[0256] Exemplarily, the network device in the embodiment of the present application may specifically be an SMF.
[0257] The following is an explanation of the relevant technical features involved in the embodiments of the present application. It should be noted that these explanations are intended to make the embodiments of the present application easier to understand and should not be regarded as limiting the scope of protection claimed by the present application.
[0258] 1. QoS Model
[0259] Currently, in 5G communication systems, in order to ensure the end-to-end service quality of services, a QoS model based on QoS flow is proposed. As shown in Figure 2, the terminal device can establish at least one PDU session (PDU session) between the access network device and the UPF on the core network side. For each PDU session, at least one QoS flow can be established between the terminal device, the access network device, and the UPF network element. Each QoS flow is identified by a QoS flow identifier (QFI), which uniquely identifies a QoS flow in the session. In addition, each QoS flow corresponds to a data radio bearer (DRB), and a DRB can correspond to one or more QoS flows.
[0260] The QoS model supports both QoS flows with guaranteed bit rates (GBR QoS flows) and QoS flows without guaranteed bit rates (non-GBR QoS flows). Packets entering the same QoS flow receive the same transmission processing (such as scheduling and admission thresholds). Whether a QoS flow is a GBR QoS flow or a non-GBR QoS flow is determined by the corresponding QoS profile.
[0261] For example, see Figure 3, which is a schematic diagram of a process for establishing a QoS flow. As shown in Figure 3, the interaction process between network elements or devices includes:
[0262] Step 301: The SMF network element instructs the terminal device, access network device, and UPF network element to establish a QoS flow based on local policies or policy and charging control (PCC) rules sent by the PCF network element. The specific establishment process is divided into three stages:
[0263] Step 301A: The SMF network element sends service data flow (SDF) information to the UPF network element. The SDF information includes a packet detection rule.
[0264] Step 301B: The SMF network element sends the QoS file of the QoS flow to the access network device through the AMF network element;
[0265] Step 301C: The SMF network element sends the QoS rule (QoS rule) to the terminal device through the AMF network element and / or the access network device, which includes packet filter information. It should be noted that both the QoS file and the packet filter are generated by the SMF according to local policies or PCC rules.
[0266] Step 302: Establish a QoS flow between the terminal device, access network device, and UPF network element. The access network device can establish a wireless data bearer (DRB) for the air interface based on the QoS file and store the binding relationship between the QoS flow and the DBR. The specific establishment process is divided into three stages:
[0267] 302A. The UPF performs QoS control of downlink data packets and QoS verification of uplink data packets according to the data packet detection rules included in the SDF information.
[0268] 302B. The access network device establishes a DRB according to the QoS file and establishes a mapping relationship between the DRB and the QoS flow.
[0269] 302C. The terminal device performs QoS control on the uplink data packet according to the QoS rule.
[0270] When data packets are transmitted between terminal devices, access network devices, and UPF network elements:
[0271] In the downlink direction, when the UPF network element receives a downlink data packet, it detects the data packet according to the SDF information sent by the SMF network element, finds the matching QoS flow according to the data packet detection rules, and carries the service quality flow identifier (QoS flow identifier, QFI) information used to identify the QoS flow in the header of the downlink data packet. When the access network device receives the downlink data packet, it confirms the available QoS flow by parsing the QFI in the header, and places the downlink data packet on the corresponding DRB for transmission based on the stored binding relationship between the QoS flow and the DRB.
[0272] In the uplink direction, when the terminal device needs to send an uplink data packet, it can determine the QoS flow according to the QoS rules, carry the QFI in the packet header of the uplink data packet, and then, based on the binding relationship between the QoS flow and the DBR, place the uplink data packet on the corresponding DRB for transmission. When the access network device receives the uplink data packet, based on the QFI in the packet header, the packet header of the uplink data packet forwarded to the UPF network element carries the QFI. When the UPF network element receives the uplink data packet sent by the access network device, it verifies whether the uplink data packet is transmitted using the correct QoS flow.
[0273] Among them, due to the different QoS files generated by SMF, the established QoS flow can include two types:
[0274] Type one is: guaranteed bit rate (GBR) QoS flow. In this case, the QoS file may include a 5G QoS identifier (5G QoS identifier, 5QI), allocation and retention priority (ARP), guaranteed flow bit rate (GFBR), and maximum bit rate (MBR) for identifying QoS attribute information. Optionally, the QoS file may also include notification control information. When the QoS file includes notification control information, the GBR QoS flow is a GBR QoS flow that requires notification control, otherwise it is a GBR QoS flow that does not require notification control. Among them, for the GBR QoS flow that requires notification control, when the access network device detects that the corresponding QoS flow resources cannot be met, the access network device notifies the session management function (SMF) network element of the event. Further, the SMF network element can initiate a QoS flow deletion or modification process. For example, when transmitting a data packet on the DRB corresponding to a certain GBR QoS flow, if the access network device detects that the service quality requirement of the GBR QoS flow cannot be met and the GBR QoS flow is configured to require notification control, then the access network device can notify the SMF network element through the AMF network element that the service quality requirement of the GBR QoS flow cannot be met, so that the SMF network element can modify or delete the GBR QoS flow according to the local policy, or the SMF network element instructs the PCF network element to modify or delete the GBR QoS flow. In one example, when the bit rate of the transmitted data packet does not reach the expected bit rate specified by the GFBR, it can be considered that the service quality requirement of the GBR QoS flow cannot be met. In another example, when the transmission delay (or packet loss rate, etc.) when transmitting the data packet does not meet the transmission delay (or packet loss rate, etc.) included in the 5QI, it can also be considered that the service quality requirement of the GBR QoS flow cannot be met.
[0275] Type 2 is a non-guaranteed bit rate (non-GBR) QoS flow. In this case, the QoS profile can include 5QI, ARP, etc.
[0276] 2. PDU Session
[0277] A PDU session is a connection between a terminal device and a data network (DN), and is used to provide a PDU connection service.
[0278] 3. 5QI
[0279] 5QI is a scalar used to index the corresponding 5G QoS feature. 5QI mainly includes one or more of the following parameters: resource type, packet delay budget (PDB), packet error rate (PER), averaging window (AW), priority level (PL) and maximum data burst volume (MDBV). For example, as shown in Table 1, when the 5QI value is 1, it means that the resource type is guaranteed bit rate (GBR) type, the priority is 20, the packet delay budget is 100ms, the packet error rate is 10-2, the maximum data burst volume is a parameter to be defined, and the averaging window is 2000ms. In other words, a 5QI value of 1 represents a set of parameters specified in the network protocol. It should be understood that Table 1 only shows the standard QoS parameters corresponding to one 5QI value. In practice, there may be different standard QoS parameters corresponding to different 5QI values, which will not be repeated in this application.
[0280] Table 1
[0281] 4. Quintuple
[0282] The quintuple includes source IP address, destination IP address, IP protocol type, source port number, and destination port number.
[0283] 5. PDU Set
[0284] A collection of multiple data packets at the transport layer corresponds to the minimum granularity of data processing at the application layer, such as a collection of frames. If the video is encoded as slices, a PDU Set refers to a collection of data packets within a slice. In some application scenarios, the application layer can only correctly parse the corresponding data unit if it correctly receives all packets in a PDU Set. In other application scenarios, the application layer can only parse the corresponding data unit if it correctly receives a certain percentage of packets within the PDU Set.
[0285] 6. PDB and PER
[0286] The PDB defines the upper limit on the transmission delay a data packet may experience between the terminal device and the N6 interface of the UPF. The PER defines an upper limit on the ratio of data packets that have been processed by the link layer (such as the RLC layer) on the transmitting end but have not been submitted to the upper layer (such as the PDCP layer) by the corresponding receiving end. The packet error rate can also be called the packet error rate, and the two are interchangeable.
[0287] 7. PSDB and PSER
[0288] PSDB defines the upper limit of the transmission delay that a data packet set (PDU Set) may experience between the terminal device and the N6 interface of the UPF. For the uplink, this delay refers to the delay from the first data packet in the PDU Set being sent from the terminal device side to the last data packet in the PDU Set arriving at the UPF N6 interface; for the downlink, it refers to the delay from the first data packet from the UPF N6 interface to the last data packet arriving at the terminal device. PSER defines an upper limit, that is, the upper limit of the ratio of data packet sets that have been processed by the link layer (such as the RLC layer) of the sending end but have not been submitted to the upper layer (such as the PDCP layer) by the corresponding receiving end.
[0289] 8. PDU Set integrated handling information (PHISI)
[0290] The PHISI indicates whether a set of packets requires all packets to be received.
[0291] 9. Processing of PDU Sets for XR Services
[0292] Support for PDU Set-based processing includes, for example, support for identifying packet data unit sets and support for packet data unit-based integrity processing, where support for packet data unit-based integrity processing includes support for packet data unit-based integrity scheduling and packet loss processing.
[0293] 10. XR service flow information
[0294] The flow information of an XR service refers to one or more attributes of the XR service, such as the IP address, port number, MAC address, etc. Typically, the flow information can be identified by an IP quintuple.
[0295] 11. Packet filter
[0296] Packet filters contain rules such as IP addresses, port numbers, MAC addresses, etc. Typically, packet filters can be in the form of IP quintuples.
[0297] 12. QoS profile
[0298] A traditional QoS profile includes information such as 5QI, GFBR, and MFBR to describe the characteristics or requirements of a QoS flow. A QoS profile that supports PDU Set-based QoS flows also includes information such as PSDB and PSER.
[0299] 13. QoS rule
[0300] A QoS rule contains a packet filter and its associated QFI information. A packet filter is used to match packets, and the QoS flow associated with the matching packet filter is the QoS flow that the packet will enter.
[0301] 14. Bidirectional QoS flow
[0302] If a QoS flow can contain both uplink and downlink service data, then the QoS flow is a bidirectional QoS flow. For example, refer to Figure 4, which is a schematic diagram of a bidirectional QoS flow provided by an embodiment of the present application. As shown in Figure 4, the service data flow of application 1 is downlink, and the service data flow of application 2 is uplink, wherein the service data flow of application 1 and service data 2 can be transmitted through the QoS flow corresponding to the same QFI (such as QFI1 in Figure 4), and the QoS flow is a bidirectional QoS flow.
[0303] The communication method and communication device provided by this application are described in detail below:
[0304] Please refer to Figure 5, which is an interactive flow diagram of the communication method provided by an embodiment of the present application. As shown in Figure 5, the communication method includes the following steps S500 to S503. The execution subject of the method shown in Figure 5 can be a terminal device and a network device, or the execution subject of the method shown in Figure 5 can also be a chip in the terminal device and a chip in the network device. For the convenience of description, Figure 5 mainly uses the terminal device and the network device as an example of the execution subject of the method. It should be noted that Figure 5 is a schematic flow chart of an embodiment of the method of the present application, showing the detailed communication steps or operations of the method, but these steps or operations are only examples. The embodiment of the present application can also perform other operations or variations of the various operations in Figure 5. In addition, the various steps in Figure 5 can be executed in a different order from that presented in Figure 5, and it may not be necessary to execute all the operations in Figure 5. Among them:
[0305] S500: The terminal device sends a PDU session establishment request to the network device. Correspondingly, the network device receives the PDU session establishment request from the terminal device.
[0306] Generally speaking, the terminal device may carry the capability information of the terminal device in the PDU session establishment request sent. For example, the capability information of the terminal device may indicate that the terminal device supports PDU Set-based processing.
[0307] Therefore, the network device can create a second QoS flow corresponding to the XR service during the PDU session establishment process based on the capability information carried in the received PDU session establishment request. According to the network policy or configuration, the second QoS flow does not support PDU Set-based processing. For example, the XR service can be a video service.
[0308] Optionally, the network device may also create corresponding QoS flows for other services (eg, voice services), which is not limited in this application.
[0309] It is understandable that the specific steps of creating a QoS flow during the PDU session establishment process can be found in the process shown in Figure 3, and this application will not go into details here.
[0310] S501: The network device sends a PDU session establishment acceptance message to the terminal device. Correspondingly, the terminal device receives the PDU session establishment acceptance message from the network device.
[0311] In some feasible implementations, the PDU session establishment acceptance message may include first indication information and second indication information, wherein the first indication information indicates the second QoS flow, and the second indication information indicates whether the second QoS flow supports PDU Set-based processing. Optionally, the PDU session establishment acceptance message may also include a 5QI associated with the second QoS flow (hereinafter described as the first 5QI for ease of description). The parameters indicated by the first 5QI may include information such as the PDB and PER of the second QoS flow.
[0312] Optionally, after the network device completes the creation of the second QoS flow, the network device may also send the QoS file of the second QoS flow to the access network device (not shown in Figure 5). The QoS file is used to create the data wireless bearer of the second QoS flow. Specifically, the QoS file may include parameters such as 5QI, which are no longer restricted here.
[0313] S502: The terminal device sends a first message to the network device. Correspondingly, the network device receives the first message from the terminal device.
[0314] Among them, the first message is used to create a first QoS flow for the XR service request, and the first QoS flow supports PDU Set-based processing. Generally speaking, the terminal device can determine whether the second QoS flow corresponding to the XR service supports PDU Set-based processing based on the PDU session establishment acceptance message. Exemplarily, the terminal device can determine the second QoS flow corresponding to the XR service based on the first indication information carried in the PDU session establishment acceptance message, and determine whether the second QoS flow corresponding to the XR service supports PDU Set-based processing based on the second indication information. That is, the first indication information and the second indication information carried in the PDU session establishment acceptance message, wherein the first indication information indicates the second QoS flow (this is because the PDU session establishment process may not only create the second QoS flow corresponding to the XR service, but it may also create QoS flows for other services, that is, multiple QoS flows may be created during the PDU session establishment process, therefore, the first indication information is required to indicate the second QoS flow corresponding to the XR service), and the second indication information indicates whether the second QoS flow supports PDU Set-based processing. In an embodiment of the present application, the terminal device can send a first message to the network device when the second QoS flow does not support PDU Set-based processing. Optionally, when the second QoS flow supports PDU Set-based processing, if the QoS parameters corresponding to the second QoS flow do not meet the QoS requirements, the terminal device can send a third message to the network device, where the third message is used to request modification of the QoS parameters corresponding to the QoS flow (for example, the second QoS flow) created for the XR service.
[0315] Exemplarily, the first indication information includes packet filter information and an identifier of an associated QoS flow, and the second QoS flow can be determined according to the packet filter information and the identifier of the associated QoS flow.
[0316] As another example, the packet filter information is included in a QoS rule of the QoS rule element, and the component type of the packet filter can be an IP address, a port number, a MAC address, etc. A packet filter may include a five-tuple information or a three-tuple information, and a five-tuple information includes a source IP address, a destination IP address, an IP protocol type, a source port number, and a destination port number. The terminal device obtains the flow information of the XR service from the inside. Optionally, if the flow information is identified by the five-tuple information, and at least one five-tuple information indicated by the first indication information matches the five-tuple information of the obtained XR service, the QoS flow corresponding to the matched five-tuple information can be determined as the second QoS flow. Here, the match between a certain five-tuple information and the five-tuple information of the XR service can be understood as each group information is exactly the same or a hash match.
[0317] Exemplarily, the length of the second indication information can be 1 bit. When the value of this 1 bit is 1, it indicates that the second QoS flow supports PDU Set-based processing. When the value of this 1 bit is 0, it indicates that the second QoS flow does not support PDU Set-based processing. If the second indication information is not carried, it can be considered that PDU Set-based processing is not supported.
[0318] As another example, the second indication information may be the QoS parameter information associated with the second QoS flow. If the QoS parameter information includes PDU Set information such as PSDB and PSER, it indicates that the second QoS flow supports PDU Set-based processing; if the QoS parameter information does not include PSDB, PSER, etc., it indicates that the second QoS flow does not support PDU Set-based processing.
[0319] In one possible implementation (1), the terminal device may also obtain first information about the XR service, where the first information includes a second QoS parameter for the XR service. The second QoS parameter includes one or more of the following: a second PSDB, a second PSER, a second PHISI, or a first tag value. Therefore, the terminal device may send a first message to the network device based on the first information. Exemplarily, the first message may include one or more of the following third QoS parameters desired by the terminal device: a third PSDB, a third PSER, a third PHISI, or a first tag value. The first tag value is used to indicate support for processing of PDU Sets in the uplink and / or downlink directions. It is understood that the terminal device sends the desired first tag value to the network device, so that the network device can establish a QoS flow that supports processing of PDU Sets in the uplink and / or downlink directions based on the first tag value. The third QoS parameter may be determined based on the second QoS parameter (or it may be understood that the terminal device may use the second QoS parameter as the third QoS parameter desired by the terminal device). The third QoS parameter carried in the first message may be understood as the QoS parameter desired by the terminal device. In a specific implementation, the above-mentioned terminal device obtains the first information of the XR service, which can be understood as: the application inside the terminal device for providing the XR service can open QoS information to the terminal device. Therefore, the application can actively report the first information corresponding to the XR service to the upper layer of the terminal device (such as the application layer). Alternatively, the terminal device can periodically read the first information of the XR service provided by the application from the application inside the terminal device. This application does not impose any restrictions on this.
[0320] For example, suppose that the second PSDB in the second QoS parameter carried in the first information of the XR service obtained from the application is 100ms and the second PSER is 10 -2 , then the terminal device can use 100ms and 10 -2 They are sent to the network device as the third PSDB and third PSER expected by the terminal device respectively.
[0321] In a possible implementation method ②, the terminal device may also send a first message to the network device when determining the XR service based on the traffic characteristics. Here, the traffic characteristics can be understood as the characteristics presented in terms of packet size, number of packets, periodicity, etc. Generally speaking, the burst type of XR service traffic appears in the form of burst. Under this implementation method ②, the terminal device can reuse the first 5QI as the third QoS parameter expected by the terminal device. Optionally, the third QoS parameter may also include one or more parameters such as the first tag value or the second tag value. Optionally, the terminal device may determine the first tag value by the source of the traffic (or service data flow) and determine the second tag value by the traffic characteristics. The first tag value is used to indicate support for PDU Set processing in the uplink and / or downlink direction, and the second tag value is used to indicate whether the first QoS flow supports PDU Set-based processing. Here, the second tag value is mainly used to indicate that the first QoS flow supports PDU Set-based processing. When the network device receives a first message carrying one or more information such as the first tag value, the second tag value, or the first 5QI, the network device can determine, based on the second tag value, that the first QoS flow to be established must support PDU Set-based processing, and then the network device can use the PDB and PER indicated by the first 5QI as the PSDB and PSER expected by the terminal device, respectively, to establish the first QoS flow.
[0322] Exemplarily, the length of the first tag value may be 2 bits, wherein when the value of the 2 bits is 01, it indicates that the XR service is a downlink service, when the value of the 2 bits is 10, it indicates that the XR service is an uplink service, and when the value of the 2 bits is 11, it indicates that the XR service can be both an uplink service and a downlink service. Another exemplary embodiment of the first tag value may also be a 2-bit bitmap, wherein each bit corresponds to a service direction, and when the value of the corresponding bit is "1", it indicates that the XR service is the corresponding service direction. For example, assuming that the service direction corresponding to the high bit is the uplink service, and the service direction corresponding to the low bit is the downlink service, when the bitmap value is 01, it indicates that the XR service is a downlink service, when the value of the 2 bits is 10, it indicates that the XR service is an uplink service, and when the value of the 2 bits is 11, it indicates that the XR service can be both an uplink service and a downlink service.
[0323] For example, the length of the second tag value can be 1 bit. When the value of this 1 bit is 1, it indicates that the first QoS flow supports PDU Set-based processing. When the value of this 1 bit is 0, it indicates that the first QoS flow does not support PDU Set-based processing. If the second tag value is not carried, it indicates that the first QoS flow does not support PDU Set-based processing.
[0324] Optionally, in addition to including the third QoS parameter expected by the terminal device, the first message may also include flow information of the XR service. It is understandable that the flow information is used to identify the XR service flow, and specifically may be in the form of a packet filter.
[0325] It is understandable that the first message involved in this application may specifically be a PDU session modification request message, etc., and this application does not impose any restrictions on this.
[0326] S503: The network device sends a second message to the terminal device. Correspondingly, the terminal device receives the second message from the network device.
[0327] Generally speaking, the network device can create a first QoS flow for the XR service based on the first message and send the first QoS parameters corresponding to the first QoS flow to the terminal device. The first QoS parameters corresponding to the first QoS flow can be carried in the second message. Here, the first QoS parameters are the QoS parameters actually configured by the network device.
[0328] It is understandable that when the above implementation method ① is adopted, the first QoS parameter may include one or more of the first PSDB, the first PSER, the first PHISI, or the first tag value. When the above implementation method ② is adopted, the first QoS parameter may include one or more of the first tag value, the second tag value, or the second 5QI. After the terminal device receives the first tag value sent by the network device, the terminal device can determine, based on the first tag value, whether the QoS flow established by the network device supports the processing of PDU Sets in the uplink direction and / or the downlink direction.
[0329] It is understandable that the second message involved in this application may specifically be a PDU session modification command message, etc., and this application does not impose any restrictions on this.
[0330] In an embodiment of the present application, after the PDU session is established, the terminal device can actively apply for / request the creation of a QoS flow for the XR service, wherein the terminal device can define and report the QoS parameters of the desired QoS flow, such as one or more of the desired PSDB, PSER, PHISI, etc. Optionally, the terminal device can also report the service direction of the XR service to be created. After the network device completes the creation of the QoS flow for the XR service based on the request of the terminal device, the network device can send to the terminal device the QoS parameters configured when the network device was actually created, such as the actually configured PSDB, PSER, PHISI or service direction, etc.
[0331] Please refer to Figure 6, which is another interactive flow diagram of the communication method provided by an embodiment of the present application. As shown in Figure 6, the communication method includes the following steps S600 to S603. The execution subject of the method shown in Figure 6 can be a terminal device and a network device, or the execution subject of the method shown in Figure 6 can also be a chip in the terminal device and a chip in the network device. For the convenience of description, Figure 6 mainly uses the terminal device and the network device as an example of the execution subject of the method. It should be noted that Figure 6 is a schematic flow chart of an embodiment of the method of the present application, showing the detailed communication steps or operations of the method, but these steps or operations are only examples. The embodiment of the present application can also perform other operations or variations of the various operations in Figure 6. In addition, the various steps in Figure 6 can be executed in a different order from that presented in Figure 6, and it is possible that not all operations in Figure 6 need to be executed. Among them:
[0332] S600: The terminal device sends a PDU session establishment request to the network device. Correspondingly, the network device receives the PDU session establishment request from the terminal device.
[0333] Generally speaking, the terminal device may carry the capability information of the terminal device in the PDU session establishment request sent. For example, the capability information of the terminal device may indicate that the terminal device supports PDU Set-based processing.
[0334] Therefore, the network device can create a third QoS flow corresponding to the XR service during the PDU session establishment process based on the capability information carried in the received PDU session establishment request. According to the network policy or configuration, the third QoS flow supports PDU Set-based processing.
[0335] Optionally, the network device may also create corresponding QoS flows for other services (eg, voice services), which is not limited in this application.
[0336] It is understandable that the specific steps of creating a QoS flow during the PDU session establishment process can be found in the process shown in Figure 3, and this application will not go into details here.
[0337] S601: The network device sends a PDU session establishment acceptance message to the terminal device. Correspondingly, the terminal device receives the PDU session establishment acceptance message from the network device.
[0338] In some feasible implementation manners, the PDU session establishment accept message may include third indication information, where the third indication information indicates a third QoS flow.
[0339] Optionally, in scenario 1, the PDU session establishment accept message further includes a fourth QoS parameter, where the fourth QoS parameter includes one or more of the following information: a fourth PDU Set delay budget PSDB, a fourth PDU Set error rate PSER, fourth PDU Set integrated processing information PHISI, or a first tag value. The first tag value is used to indicate support for PDU Set processing in the uplink direction and / or the downlink direction.
[0340] Optionally, in case 2, the PDU session establishment accept message may also include a 5QI associated with the third QoS flow (hereinafter referred to as the fourth 5QI for the convenience of description). The parameters indicated by the fourth 5QI may include information such as the PDB and PER of the third QoS flow. Optionally, in addition to including the fourth 5QI, the PDU session establishment accept message may also include a first tag value and / or a third tag value. The third tag value is used to indicate that the third QoS flow supports PDU Set-based processing.
[0341] Optionally, the network device can also send a QoS file of a third QoS flow to the access network device (not shown in Figure 6). The QoS file is used to create a data wireless bearer for the second QoS flow. Specifically, the QoS file can include parameters such as PSDB and PSER, which are no longer restricted here.
[0342] S602: The terminal device sends a third message to the network device. Correspondingly, the network device receives the third message from the terminal device.
[0343] The third message is used to request modification of a fourth QoS parameter corresponding to a third QoS flow created for the XR service.
[0344] In one implementation (1-1), if the content included in the PDU Session Establishment Accept message is the above-described scenario 1, then sending the third message to the network device can be understood as: the terminal device obtaining the fifth QoS parameter for the XR service, the fifth QoS parameter including one or more of the following information: a fifth PSDB, a fifth PSER, or a fifth PHISI. In the event that the fourth QoS parameter and the fifth QoS parameter do not match, the terminal device sends the third message to the network device based on the fifth QoS parameter. Here, the mismatch between the fourth QoS parameter and the fifth QoS parameter can be understood as one or more parameters being different, such as, for example, different PSDBs. It is understood that the first tag value is used to indicate support for uplink and / or downlink PDU Set processing. Optionally, sending the third message to the network device based on the fifth QoS parameter can be understood as determining the third QoS parameter expected by the terminal device carried in the third message based on the fifth QoS parameter. In this implementation (1-1), the third QoS parameter includes one or more of a third PSDB, a third PSER, or a third PHISI. Exemplarily, the terminal device may use the fifth PSDB, fifth PSER, or fifth PHISI carried in the five QoS parameters as the third PSDB, third PSER, or third PHISI carried in the third QoS parameter, respectively. In specific implementation, the above-mentioned terminal device obtains the fifth QoS parameter of the XR service, which can be understood as follows: the application inside the terminal device for providing the XR service can open QoS information to the terminal device, so the application can actively report the fifth QoS parameter corresponding to the XR service to the upper layer (such as the application layer) of the terminal device, or the terminal device can periodically read the fifth QoS parameter of the XR service provided by the application from the application inside the terminal device. This application does not impose any restrictions on this.
[0345] In one implementation (1-2), if the content included in the PDU session establishment acceptance message is the above-mentioned situation 1, then sending the third message to the network device can also be understood as: when the number of PDU Sets of the XR service received in the unit time is less than the first threshold, sending the third message to the network device based on the fourth QoS parameter. Among them, the number of PDU Sets of the XR service received in the unit time is less than the first threshold means that the user experience of the XR service is poor. In other words, this implementation (1-2) is mainly to apply / request the network device to modify the fourth QoS parameter of the XR service through the third message when the terminal device perceives that the effect of the XR service is not good, such as when the video is stuck. Among them, sending the third message to the network device based on the fourth QoS parameter can be understood as determining the third QoS parameter expected by the terminal device carried in the third message based on the fourth QoS parameter. In this implementation (1-2), the third QoS parameter includes one or more of the third PSDB, the third PSER, or the third PHISI. Exemplarily, the terminal device may adjust one or more of the fourth PSDB, fourth PSER, or fourth PHISI included in the fourth QoS parameter, and use the corresponding adjusted parameters as the third PSDB, third PSER, or third PHISI carried in the third QoS parameter. For example, assuming that the PSDB carried by the fourth QoS parameter is 100ms, with 100ms as the benchmark, the adjustment can be performed to obtain the value of the PSDB carried in the third QoS parameter after adjustment, such as 90ms as the PSDB required to be carried in the third QoS parameter. For another example, assuming that the PSER carried by the fourth QoS parameter is 10 -2 , with 10 -2 The PSER value carried in the third QoS parameter after adjustment can be obtained, for example, 10 -3 The PSER needs to be carried in the third QoS parameter.
[0346] In one implementation (2-1), if the content included in the PDU session establishment acceptance message is the above-mentioned situation 2, then sending the third message to the network device can be understood as: the terminal device obtains the fifth QoS parameter of the XR service, and the fifth QoS parameter includes the fifth 5QI. In the case that the fourth 5QI and the fifth 5QI do not match, a third message is sent to the network device based on the fifth 5QI. Here, the mismatch between the fourth 5QI and the fifth 5QI can be understood as the PDB or PER indicated by the fourth 5QI is different from the PDB or PER indicated by the fifth 5QI. For example, the PDB indicated by the fourth 5QI is 100ms, while the PDB indicated by the fifth 5QI is 50ms. It can be understood that the first tag value is used to indicate support for the processing of the PDU Set in the uplink direction and / or downlink direction, and the third tag value is used to indicate that the third QoS flow supports processing based on the PDU Set. Optionally, sending the third message to the network device based on the fifth 5QI here can be understood as determining the third QoS parameter expected by the terminal device carried in the third message based on the fifth 5QI. In this implementation mode (2-1), the third QoS parameter includes one or more of the third 5QI or the third tag value. Exemplarily, the terminal device may use the fifth 5QI carried in the five QoS parameters as the third 5QI carried in the third QoS parameter. In a specific implementation, the above-mentioned terminal device obtains the fifth QoS parameter of the XR service, which can be understood as follows: the application inside the terminal device for providing the XR service can open QoS information to the terminal device, so the application can actively report the fifth QoS parameter corresponding to the XR service to the upper layer of the terminal device (such as the application layer), or the terminal device can periodically read the fifth QoS parameter of the XR service provided by the application from the application inside the terminal device. This application does not impose any restrictions on this.
[0347] In one implementation (2-2), if the content included in the PDU session establishment acceptance message is the above-mentioned situation 2, then sending a third message to the network device can also be understood as: when the number of PDU Sets of the XR service received in a unit time is less than the first threshold, sending a third message to the network device based on the fourth 5QI. Among them, the number of PDU Sets of the XR service received in a unit time is less than the first threshold, which means that the user experience of the XR service is poor. In other words, this implementation (2-2) is mainly to apply / request the network device to modify the fourth QoS parameter of the XR service through the third message when the terminal device perceives that the effect of the XR service is not good, such as when the video is stuck. Among them, sending a third message to the network device based on the fourth QoS parameter can be understood as determining the third QoS parameter expected by the terminal device carried in the third message based on the fourth QoS parameter. In this implementation (2-2), the third QoS parameter includes one or more of the third 5QI or the third tag value. Exemplarily, the terminal device can adjust the fourth 5QI included in the fourth QoS parameter and use the corresponding adjusted parameter as the third 5QI carried in the third QoS parameter. For example, if the PDB indicated by the fourth 5QI is 100ms, an adjustment based on 100ms can be made to obtain the value of the PDB carried in the adjusted third QoS parameter, such as 90ms as the PDB that needs to be carried in the third QoS parameter, and then the third 5QI is determined based on the mapping relationship between 5QI and PDB.
[0348] S603: The network device sends a fourth message to the terminal device. Correspondingly, the terminal device receives the fourth message from the network device.
[0349] Among them, the fourth message includes QoS parameter update information corresponding to the third QoS flow. Generally speaking, the network device can modify / reconfigure the fourth QoS parameter corresponding to the third QoS flow created for the XR service according to the third message, and send the modified QoS parameter corresponding to the third QoS flow (for the convenience of distinction, subsequently described as the sixth QoS parameter) to the terminal device. Among them, the sixth QoS parameter can be carried in the fourth message, that is, the QoS parameter reconfigured by the network device is carried in the fourth message.
[0350] It is understandable that when the above implementations (1-1) and (1-2) are adopted, the sixth QoS parameter may include one or more of a sixth PSDB, a sixth PSER, or a sixth PHISI. When the above implementations (2-1) and (2-2) are adopted, the sixth QoS parameter may include one or more of a sixth 5QI, or a third tag value.
[0351] It is understandable that the fourth message involved in this application can specifically be a PDU session modification command message, etc., and this application does not impose any restrictions on this.
[0352] In an embodiment of the present application, after the PDU session is established, the terminal device may proactively apply for / request to modify the QoS parameters corresponding to the QoS flow established for the XR service during the PDU session establishment process, wherein the terminal device may define and report the desired QoS parameters of the QoS flow, such as one or more of the desired PSDB, PSER, PHISI (or desired 5QI), etc. After the network device completes the modification of the QoS parameters corresponding to the QoS flow of the XR service based on the request of the terminal device, the network device may send the QoS parameters reconfigured by the network device to the terminal device, such as the reconfigured PSDB, PSER, PHISI (or the reconfigured 5QI), etc.
[0353] It should be noted that steps S502 and S503 in the embodiment corresponding to FIG5 above can be used as an embodiment alone, or can be combined with one or more steps in the embodiment shown in FIG6 to form a new embodiment. For example, after executing steps S502 and S503, if the terminal device needs to modify the XR QoS parameters corresponding to the QoS flow established in S502 to S503, the terminal device can continue to execute steps S602 to S603 to modify the corresponding XR QoS parameters. It should be noted that when steps S502, S503, S602 and S603 are combined to form a new embodiment, the third QoS flow in S602 and S603 should be replaced by the first QoS flow in S502 and S503, and accordingly, the parameters / information related to the third QoS flow should also be replaced by the parameters / information related to the first QoS flow.
[0354] The communication device provided in this application will be described in detail below with reference to FIG. 7 to FIG. 9 .
[0355] It is understandable that, in order to realize the above functions, each device for implementing the above functions includes a hardware structure and / or software module for executing each function. It should be easily appreciated by those skilled in the art that, in combination with the units and algorithm steps of each example described in the embodiments disclosed herein, the present application can be implemented in the form of hardware or a combination of hardware and computer software. Whether a function is executed in the form of hardware or computer software driving hardware depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.
[0356] In the embodiment of the present application, the terminal device or network device (such as SMF) can be divided into functional modules according to the above method example. For example, each functional module can be divided according to each function, or two or more functions can be integrated into one processing module. The above integrated module can be implemented in the form of hardware or in the form of software functional modules. It should be noted that the division of modules in the embodiment of the present application is schematic and is only a logical functional division. In actual implementation, there may be other division methods.
[0357] Please refer to Figure 7, which is a structural diagram of a communication device provided in an embodiment of the present application. The communication device 700 shown in Figure 7 can be used to perform part or all of the functions of the terminal device in the method embodiments described in Figures 5 and 6 above. The device can be a terminal device, or a device in a terminal device, or a device that can be used in combination with a terminal device. Among them, the communication device can also be a chip or a chip system. The communication device shown in Figure 7 may include a transceiver unit 701 and a processing unit 702. Among them, the processing unit 702 is used to perform data processing. The transceiver unit 701 integrates a receiving unit and a sending unit. The transceiver unit 701 can also be called a communication unit. Alternatively, the transceiver unit 701 can also be split into a receiving unit and a sending unit. The processing unit 702 and the transceiver unit 701 below are similar and will not be repeated below. Among them:
[0358] In one implementation:
[0359] The transceiver unit 701 is configured to send a first message to a network device, where the first message is used to create a first quality of service (QoS) flow for an extended reality (XR) service request, where the first QoS flow supports processing based on a packet data unit set (PDU Set);
[0360] The transceiver unit 701 is configured to receive a second message from the network device, where the second message includes a first QoS parameter corresponding to the first QoS flow.
[0361] The processing unit 702 is configured to generate a first message, process a second message, and so on.
[0362] In another implementation:
[0363] The transceiver unit 701 is configured to send a third message to the network device, wherein the third message is used to request modification of a fourth QoS parameter corresponding to a third quality of service flow QoS flow created for the extended reality (XR) service; the third QoS flow supports processing based on a packet data unit set (PDU Set);
[0364] The transceiver unit 701 is configured to receive a fourth message from the network device, where the fourth message includes QoS parameter update information corresponding to the third QoS flow.
[0365] The processing unit 702 is configured to generate a third message, process a fourth message, and so on.
[0366] For other possible implementations of the communication device, please refer to the relevant description of the terminal device functions in the method embodiments corresponding to Figures 5 and 6 above, which will not be repeated here.
[0367] Please refer to Figure 8, which is a structural diagram of another communication device provided in an embodiment of the present application. The communication device 800 shown in Figure 8 can be used to perform some or all of the functions of the network device in the method embodiments described in Figures 5 and 6 above. The device can be a network device, or a device in a network device, or a device that can be used in conjunction with a network device. Exemplarily, the network device can be a network element such as an SMF. Among them, the communication device can also be a chip or a chip system. The communication device shown in Figure 8 may include a transceiver unit 801 and a processing unit 802. Among them:
[0368] In one implementation:
[0369] The transceiver unit 801 is configured to receive a first message from a terminal device, where the first message is used to create a first quality of service (QoS) flow for an extended reality (XR) service request, where the first QoS flow supports processing based on a packet data unit set (PDU Set);
[0370] The transceiver unit 801 is used to send a second message to the terminal device, where the second message includes a first QoS parameter corresponding to the first QoS flow.
[0371] The processing unit 802 is configured to process the first message, generate a second message, and so on.
[0372] In another implementation:
[0373] The transceiver unit 801 is configured to receive a third message from a terminal device, the third message being used to request modification of a fourth QoS parameter corresponding to a third quality of service flow QoS flow created for an extended reality (XR) service; the third QoS flow supports processing based on a packet data unit set (PDU Set);
[0374] The transceiver unit 801 is configured to send a fourth message to the terminal device, where the fourth message includes QoS parameter update information corresponding to the third QoS flow.
[0375] The processing unit 802 is configured to process the third message, generate a fourth message, and so on.
[0376] For other possible implementations of the communication device, reference may be made to the relevant descriptions of the network device functions in the method embodiments corresponding to FIG5 and FIG6 , which will not be described in detail here.
[0377] In one possible embodiment, when the terminal device or network device (e.g., SMF) is a chip, the transceiver unit may be a communication interface, a pin, or a circuit. The communication interface may be used to input data to be processed into the processor and to output the processing results of the processor. In a specific implementation, the communication interface may be a general purpose input and output (GPIO) interface that can be connected to multiple peripheral devices (e.g., a display (LCD), a camera (camara), a radio frequency (RF) module, an antenna, etc.). The communication interface is connected to the processor via a bus.
[0378] The processing unit may be a processor that can execute computer-executable instructions stored in the storage unit to enable the chip to execute the methods involved in FIG. 5 and FIG. 6 .
[0379] Furthermore, the processor may include a controller, an arithmetic unit and a register. For example, the controller is mainly responsible for decoding instructions and issuing control signals for operations corresponding to the instructions. The arithmetic unit is mainly responsible for performing fixed-point or floating-point arithmetic operations, shift operations and logical operations, etc., and can also perform address operations and conversions. The register is mainly responsible for storing register operands and intermediate operation results temporarily stored during the execution of instructions. In a specific implementation, the hardware architecture of the processor can be an ASIC architecture, a microprocessor without interlocked piped stages architecture (MIPS) architecture, an advanced RISC machines (ARM) architecture or a network processor (NP) architecture, etc. The processor can be single-core or multi-core.
[0380] The storage unit may be a storage unit within the chip, such as a register, cache, etc. The storage unit may also be a storage unit located outside the chip, such as a ROM or other type of static storage device that can store static information and instructions, RAM, etc.
[0381] It should be noted that the functions corresponding to the processor and the interface can be implemented through hardware design, software design, or a combination of hardware and software, and there is no limitation here.
[0382] Please refer to Figure 9, which is a schematic diagram of the structure of another communication device provided in an embodiment of the present application. The communication device 900 includes a processor 910 and an interface circuit 920. The processor 910 and the interface circuit 920 are coupled to each other. It is understood that the interface circuit 920 can be a transceiver or an input / output interface. Optionally, the communication device may further include a memory 930 for storing instructions executed by the processor 910, or storing input data required by the processor 910 to execute instructions, or storing data generated after the processor 910 executes instructions.
[0383] When the communication device is used to implement the method in the above method embodiment, the processor 910 is used to execute the functions of the above processing unit, and the interface circuit 920 is used to execute the functions of the above transceiver unit.
[0384] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or may be other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.
[0385] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, which can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and storage medium can be located in an ASIC. In addition, the ASIC can be located in a terminal device or a network device. Of course, the processor and storage medium can also exist as discrete components in a terminal device or a network device.
[0386] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer programs or instructions. When the computer program or instruction is loaded and executed on a computer, the process or function described in the embodiment of the present application is executed in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer program or instruction can be stored in a computer-readable storage medium or transmitted via the computer-readable storage medium. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server that integrates one or more available media. The available medium can be a magnetic medium, such as a floppy disk, a hard disk, or a tape; it can also be an optical medium, such as a digital versatile disc (DVD); it can also be a semiconductor medium, such as a solid state drive (SSD).
[0387] In the various embodiments of the present application, unless otherwise specified or there is a logical conflict, the terms and / or descriptions between different embodiments are consistent and can be referenced by each other. The technical features in different embodiments can be combined to form new embodiments according to their inherent logical relationships.
[0388] It is understood that the various numbers used in the embodiments of this application are merely for ease of description and are not intended to limit the scope of the embodiments of this application. The order of the sequence numbers of the above-mentioned processes does not necessarily imply a specific order of execution; the order of execution of the processes should be determined by their functions and inherent logic.
[0389] An embodiment of the present application further provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed, the method executed by the terminal device or network device in the above method embodiment is implemented.
[0390] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed, the method executed by the terminal device or network device in the above method embodiment is implemented.
[0391] The present application also provides a communication system including a terminal device or a network device. The terminal device is configured to execute the method executed by the terminal device in the above method embodiment. The network device is configured to execute the method executed by the network device in the above method embodiment.
[0392] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this application.
[0393] The descriptions of the various embodiments provided in this application can refer to each other. The descriptions of each embodiment have their own focus. For parts not described in detail in a particular embodiment, please refer to the relevant descriptions of other embodiments. For the convenience and brevity of description, for example, the functions and execution steps of the various devices and equipment provided in the embodiments of this application can refer to the relevant descriptions of the method embodiments of this application. The various method embodiments and the various device embodiments can also refer to, be combined with, or quote each other.
[0394] Those skilled in the art will appreciate that the units and steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0395] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of the units is merely a logical functional division. The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the present embodiment.
[0396] If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art, or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned computer-readable storage medium can be any available medium that can be accessed by a computer. By way of example and not limitation, computer-readable media may include random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM), universal serial bus flash disk, mobile hard disk, or other optical disk storage, magnetic disk storage media or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and can be accessed by a computer. In addition, by way of example and not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous link dynamic random access memory (SLDRAM), or direct rambus RAM (DR RAM).
[0397] The above description is merely a specific embodiment of the present application, but the scope of protection of the embodiments of the present application is not limited thereto. Any person skilled in the art can easily conceive of changes or substitutions within the technical scope disclosed in the embodiments of the present application, and such changes or substitutions should be included in the scope of protection of the embodiments of the present application. Therefore, the scope of protection of the embodiments of the present application should be based on the scope of protection of the claims.
Claims
1. A communication method, characterized in that: Applied to a terminal device, the method comprises: Sending a first message to a network device, where the first message is used to create a first quality of service flow QoS flow for an extended reality XR service request, where the first QoS flow supports processing based on a packet data unit set PDU Set; A second message is received from the network device, where the second message includes a first QoS parameter corresponding to the first QoS flow.
2. The method according to claim 1, characterized in that Before sending the first message to the network device, the method further includes: Sending a PDU session establishment request to the network device; Receiving a PDU session establishment acceptance message from the network device; The sending a first message to the network device includes: Determining, according to the PDU session establishment acceptance message, whether the second QoS flow corresponding to the XR service supports PDU Set-based processing; In a case where the second QoS flow does not support PDU Set-based processing, the first message is sent to the network device.
3. The method according to claim 2, characterized in that The PDU session establishment acceptance message includes first indication information and second indication information; The first indication information indicates the second QoS flow; The second indication information indicates whether the second QoS flow supports PDU Set-based processing.
4. The method according to any one of claims 1 to 3, characterized in that: The sending a first message to the network device includes: Acquire first information of the XR service, where the first information includes a second QoS parameter of the XR service, where the second QoS parameter includes one or more of the following information: a second PDU Set delay budget PSDB, a second PDU Set error rate PSER, or second PDU Set integrated processing information PHISI; The first message is sent to the network device according to the first information.
5. The method according to claim 4, characterized in that The first message includes one or more of the following third QoS parameters expected by the terminal device: a third PSDB, a third PSER, a third PHISI, or a first tag value; The first marking value is used to indicate the processing of the PDU Set supporting the uplink direction and / or the downlink direction, and the third QoS parameter is determined based on the second QoS parameter.
6. The method according to claim 5, characterized in that The first QoS parameter includes one or more of the following QoS parameters configured by the network device: A first PSDB, a first PSER, a first PHISI, or a first tag value.
7. The method according to any one of claims 1 to 3, characterized in that: The sending a first message to the network device includes: When the XR service is determined according to the traffic characteristics, the first message is sent to the network device.
8. The method according to claim 7, characterized in that The first message includes one or more of the following third QoS parameters expected by the terminal device: A first tag value, a second tag value, or a first 5QI; the first tag value is used to indicate support for PDU Set processing in the uplink direction and / or downlink direction, the second tag value is used to indicate that the first QoS flow supports PDU Set-based processing, the parameters indicated by the first 5QI include packet delay budget PDB and packet error rate PER, and the first 5QI is the 5QI associated with the second QoS flow.
9. The method according to claim 7, characterized in that: The first QoS parameter includes one or more of the following QoS parameters configured by the network device: A first tag value, a second tag value, or a second 5QI.
10. The method according to any one of claims 1 to 9, characterized in that: The first message is a PDU session modification request message, and / or the second message is a PDU session modification command message.
11. The method according to any one of claims 1 to 10, characterized in that: The first message includes flow information of the XR service.
12. A communication method, characterized in that: Applied to a terminal device, the method comprises: Sending a third message to the network device, where the third message is used to request modification of a fourth QoS parameter corresponding to a third quality of service flow QoS flow created for the extended reality XR service; where the third QoS flow supports processing based on a packet data unit set PDU Set; A fourth message is received from the network device, where the fourth message includes QoS parameter update information corresponding to the third QoS flow.
13. The method according to claim 12, characterized in that Before sending the third message to the network device, the method further includes: Sending a PDU session establishment request to the network device; A PDU session establishment accept message is received from the network device, where the PDU session establishment accept message includes third indication information, and the third indication information indicates the third QoS flow.
14. The method according to claim 13, characterized in that The PDU session establishment acceptance message also includes the fourth QoS parameter, where the fourth QoS parameter includes one or more of the following information: a fourth PDU Set delay budget PSDB, a fourth PDU Set error rate PSER, a fourth PDU Set integrated processing information PHISI, or a first tag value; The first flag value is used to indicate the processing of the PDU Set supporting the uplink direction and / or the downlink direction; The sending a third message to the network device includes: Acquire a fifth QoS parameter of the XR service, where the fifth QoS parameter includes one or more of the following information: a fifth PSDB, a fifth PSER, or a fifth PHISI; In a case where the fourth QoS parameter does not match the fifth QoS parameter, the third message is sent to the network device based on the fifth QoS parameter.
15. The method according to claim 13, characterized in that The PDU session establishment accept message also includes the fourth QoS parameter, where the fourth QoS parameter includes one or more of the following information: a fourth PSDB, a fourth PSER, a fourth PHISI, or a first tag value; The first flag value is used to indicate the processing of the PDU Set supporting the uplink direction and / or the downlink direction; The sending a third message to the network device includes: When the number of PDU Sets of the XR service received in a unit time is less than a first threshold, the third message is sent to the network device based on the fourth QoS parameter.
16. The method according to claim 14 or 15, characterized in that The third message includes one or more of the following third QoS parameters expected by the terminal device: a third PSDB, a third PSER, or a third PHISI; The third QoS parameter is determined based on the fourth QoS parameter, or the third QoS parameter is determined based on the fifth QoS parameter.
17. The method according to claim 16, characterized in that The QoS parameter update information includes one or more of the following sixth QoS parameters reconfigured by the network device: A sixth PSDB, a sixth PSER, or a sixth PHISI.
18. The method according to claim 13, characterized in that The PDU session establishment accept message also includes a fourth QoS parameter, and the fourth QoS parameter includes one or more of the following information: a fourth 5QI, a first tag value, or a third tag value; the first tag value is used to indicate that the processing of the PDU Set in the uplink direction and / or the downlink direction is supported, and the third tag value is used to indicate that the third QoS flow supports the processing based on the PDU Set; The sending a third message to the network device includes: Acquire a fifth QoS parameter of the XR service, where the fifth QoS parameter includes a fifth 5QI; In a case where the fourth 5QI and the fifth 5QI do not match, the third message is sent to the network device based on the fifth 5QI.
19. The method according to claim 13, characterized in that The PDU session establishment accept message also includes a fourth QoS parameter, and the fourth QoS parameter includes one or more of the following information: a fourth 5QI, a first tag value, or a third tag value; the first tag value is used to indicate that the processing of the PDU Set in the uplink direction and / or the downlink direction is supported, and the third tag value is used to indicate that the third QoS flow supports the processing based on the PDU Set; The sending a third message to the network device includes: When the number of PDU Sets of the XR service received in a unit time is less than a first threshold, the third message is sent to the network device based on the fourth 5QI.
20. The method according to claim 18 or 19, characterized in that The third message includes one or more of the following third QoS parameters expected by the terminal device: A third 5QI, or a third marking value; The third 5QI is determined based on the fourth 5QI parameter, or the third QoS parameter is determined based on the fifth 5QI.
21. The method according to claim 20, characterized in that The QoS parameter update information includes one or more of the following sixth QoS parameters reconfigured by the network device: Sixth 5QI, or third marker value.
22. The method according to any one of claims 12 to 21, characterized in that: The third message is a PDU session modification request message, and / or the fourth message is a PDU session modification command message.
23. A communication method, characterized in that: Applied to a network device, the method comprises: Receive a first message from a terminal device, where the first message is used to create a first quality of service flow QoS flow for an extended reality XR service request, where the first QoS flow supports processing based on a packet data unit set PDU Set; A second message is sent to the terminal device, where the second message includes a first QoS parameter corresponding to the first QoS flow.
24. The method according to claim 23, characterized in that Before receiving the first message from the terminal device, the method further includes: Receiving a PDU session establishment request from the terminal device; Send a PDU session establishment accept message to the terminal device; the PDU session establishment accept message is used to determine whether the second QoS flow corresponding to the XR service supports PDU Set-based processing.
25. A communication method, characterized in that: Applied to a network device, the method comprises: receiving a third message from the terminal device, wherein the third message is used to request modification of a fourth QoS parameter corresponding to a third quality of service flow QoS flow created for the extended reality XR service; wherein the third QoS flow supports processing based on a packet data unit set PDU Set; A fourth message is sent to the terminal device, where the fourth message includes QoS parameter update information corresponding to the third QoS flow.
26. The method according to claim 25, characterized in that Before receiving the third message from the terminal device, the method further includes: Receiving a PDU session establishment request from the terminal device; A PDU session establishment acceptance message is sent to the terminal device, wherein the PDU session establishment acceptance message includes third indication information, and the third indication information indicates the third QoS flow.
27. A communication device, comprising a unit or module for executing the method as described in any one of claims 1-11, or a unit or module for executing the method as described in any one of claims 12-22, or a unit or module for executing the method as described in any one of claims 23-24, or a unit or module for executing the method as described in any one of claims 25-26.
28. A communication device, characterized in that: It includes a processor and an interface circuit, wherein the interface circuit is used to receive signals from other communication devices outside the communication device and transmit them to the processor or send signals from the processor to other communication devices outside the communication device, and the processor is used to implement the method as described in any one of claims 1-11, or implement the method as described in any one of claims 12-22, or implement the method as described in any one of claims 23-24, or implement the method as described in any one of claims 25-26 through logic circuits or execution code instructions.
29. A computer-readable storage medium, characterized in that: The storage medium stores a computer program or instruction. When the computer program or instruction is executed by the communication device, it implements the method as described in any one of claims 1 to 11, or implements the method as described in any one of claims 12 to 22, or implements the method as described in any one of claims 23 to 24, or implements the method as described in any one of claims 25 to 26.
30. A computer program product, characterized in that Comprising computer program code, when the computer program code is run on a computer, to implement the method as claimed in any one of claims 1 to 11, or to implement the method as claimed in any one of claims 12 to 22, or to implement the method as claimed in any one of claims 23 to 24, or to implement the method as claimed in any one of claims 25 to 26.
31. A communication system, characterized in that: It includes a terminal device and a network device, wherein the terminal device is used to implement the method described in any one of claims 1 to 11 or the method described in any one of claims 12 to 22, and the network device is used to implement the method described in any one of claims 23 to 24 or the method described in any one of claims 25 to 26.
Citation Information
Patent Citations
Data transmission method and device
CN116156668A
A system and method for reducing damage to occupants due to collision
KR1020250035064A
Packet delay parameter obtaining method, system, and apparatus
US20220014475A1