Service quality determination

Abstract

Examples include a method for determining Quality of Service (QoS) parameters, the method including receiving, at a base station, a QoS parameter request for a session from a sending entity, where the request includes a descriptor of the session and an indication that the session is a probe session. The method further includes determining, at the base station, QoS parameters associated with the probe session; and sending, by the base station, the determined QoS parameters to a receiving entity.

Description

Technical Field

[0001] The present invention generally relates to a method, a computer-readable storage medium, and an apparatus for determining quality of service. Background Art

[0002] Some communication networks operate within temporal constraints to send data between network entities within a predictable time window. Such networks may have a centralized architecture, a distributed architecture, or a hybrid architecture. Summary of the Invention

[0003] The present invention is defined by the appended independent claims. Additional features and advantages of the concepts disclosed herein are set forth in the following description.

[0004] The present disclosure describes a method for determining quality of service (QoS) parameters, the method comprising:

[0005] - receiving, at a base station, a QoS parameter request for a session from a sending entity, wherein the request comprises a descriptor of the session and an indication that the session is a probe session;

[0006] - determining, at the base station, the QoS parameters associated with the probe session; and

[0007] - sending, by the base station, the determined QoS parameters to a receiving entity.

[0008] Such a method enables the proactive determination of QoS parameters by querying the base station, rather than in an iterative trial-and-error reactive manner to determine such QoS parameters.

[0009] Optionally, the sending entity and the receiving entity are the same entity. This allows, for example, operating such a method in a centralized communication network, where the sending and receiving entities act as a central control entity.

[0010] Optionally, the sending entity and the receiving entity are time-sensitive network application function (TSN-AF) entities. In some examples, this allows integrating a wireless communication system, such as a 5G system, as a TSN bridge into a TSN network.

[0011] Optionally, the request comprises a plurality of messages. This allows simplifying the requested communication into a plurality of dedicated messages, each message carrying a specific element of the request.

[0012] Optionally, the base station does not reserve resources as an action with respect to the request. This enables determining QoS parameters by querying the base station about such QoS parameters for a given session without opening such a session, thus not affecting existing open sessions and resources at the base station.

[0013] Optionally, the QoS parameter request includes a QoS parameter determination context, where the QoS parameter determination context includes parameter determination constraints and an indication of the type of QoS parameter determined within the parameter determination constraints. This enables precise determination of QoS parameters by explicitly providing information related to the type of QoS parameter to be determined and the conditions under which such QoS parameters should be determined. More specifically, in some cases, the parameter determination constraints include one or more of a maximum bit rate, a priority, or a packet error rate, and the type of QoS parameter determined within the parameter determination constraints includes delay information. This is particularly applicable to integrating wireless bridges in time-sensitive networks.

[0014] Optionally, the request includes a probe flag, where the probe flag indicates that the probe session is to be considered as replacing the current active session at the base station, or the probe flag indicates that the probe session is to be considered in addition to the current active session at the base station. In this case, including such an explicit probe flag allows the base station to consider future expected behavior in order to more precisely determine QoS parameters.

[0015] Optionally, determining QoS parameters related to a probe session at a base station includes: the base station establishing a resource reservation plan for the probe session. Establishing such a resource reservation plan can assist the base station in more precisely determining QoS parameters without having to open a session specifically for this purpose.

[0016] Optionally, determining QoS parameters related to a probe session at a base station includes preventing the establishment of an active session at the base station and includes preventing the release of the current active session at the base station. Freezing such a system at the base station during QoS determination ensures that the system remains stable during such determination.

[0017] Optionally, the QoS parameter request further relates to one or more additional sessions, the descriptor further relates to one or more additional sessions, and the indication further indicates that one or more additional sessions are one or more additional probe sessions. This allows for QoS determination for a given multi-session topology. More specifically, determining QoS parameters related to a probe session at a base station includes: the base station determining QoS parameters related to one or more additional probe sessions; and the base station establishing a resource reservation plan for the probe session and for one or more additional probe sessions. Establishing such a plan enables QoS determination without having to open multiple sessions for this purpose.

[0018] The present disclosure also describes a method for determining quality of service (QoS) parameters, the method including:

[0019] - The sending entity sends a QoS parameter request for a session to a plurality of base stations, where each request includes a descriptor for the session and an indication that the session is a probe session;

[0020] - At the sending entity, receive specific QoS parameters related to the probe session from each of the plurality of base stations;

[0021] - The sending entity compiles the received base-station-specific QoS parameters into a QoS profile; and

[0022] - The sending entity sends the QoS profile to a control entity.

[0023] Such a method realizes the proactive determination of QoS parameters by querying multiple base stations in a centralized manner, rather than determining such QoS parameters by using an iterative trial-and-error response process.

[0024] The present disclosure also describes a computer-readable storage medium including instructions that, when executed by a processor of a computing device, cause the processor to execute any method described herein.

[0025] The present disclosure also describes a device including a processor, a memory, and a networking module, where the processor is configured to operate according to any method described herein. Description of the Drawings

[0026] Figure 1

[0027] Figure 1 Illustrates an example method.

[0028] Figure 2

[0029] Figure 2 Illustrates another example method.

[0030] Figure 3

[0031] Figure 3 Illustrates an example device.

[0032] Figure 4

[0033] Figure 4 Illustrates an example of the device architecture for applying the example method.

[0034] Figure 5

[0035] Figure 5 Illustrates an example of the device architecture for applying the example method.

[0036] ​​​​​​​​​​​Figure 6

[0037] Figure 6 Illustrates an example of an apparatus architecture for applying an example method.

[0038] Figure 7

[0039] Figure 7 Illustrates another example method.

[0040] Figure 8

[0041] Figure 8 Illustrates yet another example method.

[0042] Figure 9

[0043] Figure 9 Illustrates still another example method. Detailed implementation

[0044] The present disclosure is applicable to a method for determining Quality of Service (QoS) parameters. The QoS parameters should be understood as one or more metrics of the communication quality in a network. Examples of QoS parameters may relate to throughput, transmission delay, priority, protection, error rate, or resilience. Throughput can be defined as the number of bits successfully transmitted between entities during a defined amount of time. Transmission delay can be defined as the elapsed time for successfully transmitting data between two entities. Priority can be defined as the relative importance of a connection between two entities, whereby a lower priority can result in a degraded connection quality or even a release of resources. Protection can be defined as the degree to which an entity attempts to prevent unauthorized monitoring or manipulation of the transmitted data. Error rate can be defined as the ratio of the total incorrect, lost, and duplicate data transmitted between two entities over a period of time to the total data. Resilience can be defined as the probability that an entity disconnects or resets a connection during a given time interval.

[0045] Figure 1 Discloses an example method 100 for determining Quality of Service (QoS) parameters according to the present disclosure. Method 100 includes block 101, which illustrates receiving, at a base station, a QoS parameter request for a session from a transmitting entity, whereby the request includes a descriptor of the session and an indication that the session is a probe session.

[0046] ​​​​​​​In the present disclosure, a base station should be understood as a transceiver in a wireless communication network. The base station can communicate with other base stations, communicate with different network entities, and communicate with mobile devices located within the wireless communication range of the base station. Mobile devices located within the wireless communication range of the base station can be considered to be located in a cell of the base station of interest, and the cell is included in a cellular network. In some examples, the base station is a 5G base station. In some cases, the base station is a fixed transceiver in a wireless communication network.

[0047] As shown in block 101, the base station receives a QoS parameter request for a session. A session should be understood as an association between a mobile device providing a data exchange service and a data network. Example sessions are according to 3GPP 23.501. For example, a session can be related to a specific communication protocol such as a Packet Data Unit (PDU) session. In some cases, a session can provide several data exchange services with different QoS characteristics. The QoS parameter request is for the session because the QoS parameters apply to the QoS of the communication that will occur using such a session or data communication exchange association. In some cases, multiple communication services can be included in a single session. The QoS parameters can apply to each, a subset, or all of the sessions or communication services that can be included in the session.

[0048] As shown in block 101, the base station receives a QoS parameter request for a session from a sending entity. The sending entity should be understood as a network entity that is a hardware or virtual network entity. The sending entity can send wirelessly or by wire. The sending entity can be part of a chain of sending entities, whereby the QoS parameters can be sent from a first sending entity to a second sending entity, from the second sending entity to a third sending entity, and from the third sending entity to the base station. In this case, the third sending entity sends the QoS request directly to the base station, while the second sending entity or the first sending entity sends the QoS request indirectly to the base station. In some cases, the sending entity generates the QoS request. Examples of the sending entity include TSN-AF (Application Function), SMF (Session Management Function), or AMF (Access and Mobility Function).

[0049] As shown in block 101, the request includes a descriptor of the session. Such a descriptor should be understood as a descriptor of a session profile, which includes, for example, one or more of a protocol version number, an initiator and session identifier, a session name, bandwidth information, encryption information, or an active session time. Such a descriptor provides information that allows the base station to determine the type and nature of the session associated with the descriptor.

[0050] As shown in block 101, the request includes an indication that the session is a probe session. This indication should be understood as indicating to the base station that the session associated with the descriptor is for probing purposes. The base station can then be in a position to take into account that a probe session is different from a session that should be effectively established to effectively send or receive data.

[0051] Method 100 further includes block 102, which illustrates determining QoS parameters associated with the probe session at the base station. The determination of the QoS parameters occurs at the base station to enable proactive determination of QoS. Having the base station determine itself, QoS allows for a particularly precise and rapid determination of such QoS, due to the fact that the base station has direct visibility of the network limitations at its level.

[0052] Method 100 further includes block 103, which illustrates sending the determined QoS parameters from the base station to the receiving entity. Such a transmission allows the receiving entity to be notified of the determined QoS parameters, whereby such a receiving entity can, for example, consider this information to integrate the radio communication system including the base station of interest into a wider communication system.

[0053] In some examples, the sending entity and the receiving entity are the same entity. In some examples, the QoS parameter request follows a given path through multiple sending entities, and the determined QoS parameters follow a return path that corresponds to the same path as the path followed by the request. In an example, the request is passed from a first sending entity to a second sending entity and a third sending entity in this order, and the associated determined QoS parameters are received at the third entity, the second entity, and the first entity in this order. In an example, the entity is a TSN-AF entity. In an example, the entity is an SMF entity. In an example, the entity is an AMF entity. In an example, the QoS parameter request is sent from TSN-AF to SMF, from SMF to AMF, and from AMF to the base station, and the determined QoS parameters are received at the AMF from the base station, received by the SMF from the AMF, and received by the TSN-AF from the SMF. TSM-AF can act as a converter for the control plane of a TSN system, such as a centralized architecture including a CNC (Centralized Network Configuration) node. Such a process allows, for example, integrating a 5G system including a base station as a TSN bridge into a TSN system. In some cases, such examples can be implemented in a method as shown in Figure 1 as shown.

[0054] In some examples, a request includes a number of messages. A message should be understood as a communication unit between two network entities. While in some examples the request can be sent in a single message, the request can also be sent using a number of messages. In some examples, a first message includes an indication that the session is a probe session, and a second message includes a descriptor of the session. Other combinations can be considered, which can depend on protocol-related message sizes. In some cases, these examples can be implemented in a method as shown in Figure 1 as shown.

[0055] In some examples, the base station does not take resource reservation as an action with respect to the request. In some examples, the base station prevents resource reservation in response to the session being identified as a probe session. In some examples, since the session is identified as a probe session, no currently active session at the base session is affected in terms of resources. In some examples, none of the resources controlled by the base station are allocated to the probe session. Such resources can include, for example, radio resources, memory resources, or one or more of computing or processing resources. This allows avoiding affecting the performance or QoS of currently active sessions. In some cases, such examples can be implemented in a method as shown in Figure 1 as shown.

[0056] In some examples, the QoS parameter request includes a QoS parameter determination context, where the QoS parameter determination context includes parameter determination constraints and an indication of the type of QoS parameter determined within the parameter determination constraints. The QoS determination constraints should be understood as information that allows determining under which conditions the QoS parameters should be determined. More specifically, the QoS parameter determination constraints can include one or more of a maximum bit rate (or maximum throughput), a priority, or a packet error rate. Other examples of information that can be included in the QoS parameter determination constraints are protection or resilience information or data packet size. The base station can actually be in a position to consider the probe session in different contexts or under different constraints, each context or constraint leading to different QoS parameters. The parameter determination constraints can be communicated using exact values, using thresholds, or using ranges. In some examples, the type of QoS parameter determined within the parameter determination constraints includes delay information. For example, if the constraint includes a specific maximum bit rate or a specific throughput, the type of QoS parameter to be determined can include the minimum and maximum delays that the base station can guarantee when considering the given constraint. For example, if the constraint includes a maximum bit rate and delay information, the type of QoS parameter to be determined can include the maximum error rate that the base station can guarantee when considering the given constraint. In other words, the QoS can correspond to multiple variables, and the constraints result in setting or reducing the variability of some of the variables in order to determine the value of another variable corresponding to the QoS parameter to be determined. In some cases, these examples can be implemented in a method as shown in Figure 1Implemented in the method shown. In some cases, multiple communication services can be included in a single session. The QoS parameter determination context can be applied to each, subset, or all of the sessions or communication services that can be included in the session.

[0057] In some examples, the request includes a probe flag that indicates that the probe session is to be considered as replacing the current active session at the serving base station, or the probe flag indicates that the probe session is to be considered in addition to the current active session at the serving base station. The probe flag should be understood as additional information that the serving base station can consider in order to more precisely determine QoS parameters. For example, if the probe flag indicates that the probe session is to be considered as replacing the current active session, it is possible that the serving base station will consider allocating one or more performant resources to the probe session as compared to the case where the probe flag indicates that the probe session will be in addition to the current active session (in which case the resources that would be considered available for the probe session would actually be more restricted). In some examples, regardless of the indication it provides, the probe flag does not have a precise impact on the current active session since it refers to the probe session rather than an effectively established session. In some cases, such examples can be implemented in a method as shown in Figure 1 Implemented in the method shown.

[0058] In some examples, the QoS parameter request also relates to one or more additional sessions, the descriptor also relates to one or more additional sessions, and the indication also indicates that one or more additional sessions are one or more additional probe sessions. In such a case, the QoS parameters allow for the description of a topology that includes multiple sessions in order to determine QoS parameters at the serving base station, each of the various sessions being a probe session according to the present disclosure. More specifically, in such a case, an example method would, for example, include: determining at the serving base station QoS parameters associated with one or more additional probe sessions; and establishing at the serving base station a resource reservation plan for the probe session and for one or more additional probe sessions. In some cases, each probe session is associated with a specifically determined QoS parameter. In some cases, the specifically determined QoS parameter relates to several probe sessions. In some cases, the specifically determined QoS parameter relates to all probe sessions. In some cases, such examples can be implemented in a method as shown in Figure 1 Implemented in the method shown.

[0059] It should be understood that the resource reservation plan is for the purposes of the plan according to the present disclosure and does not imply the reservation of such resources when in the planning phase of establishing the resource reservation plan.

[0060] Figure 2Illustrates an example method 200 for determining Quality of Service (QoS) parameters according to the present disclosure. Method 200 includes, as shown in block 201, sending, by a sending entity, a QoS parameter request for a session to a plurality of base stations, where each request includes a descriptor of the session and an indication that the session is a probe session. From the perspective of the sending entity, method 200 can be seen, and in some cases, method 200 can be executed together with a method such as example method 100 as seen from the perspective of the base station. Method 200 is applicable to a plurality of base stations, where each of the plurality of base stations can operate an exemplary method 100.

[0061] As shown in block 202, method 200 includes receiving, at the sending entity, specific QoS parameters related to the probe session from each of the plurality of base stations. This allows various QoS parameters to be collected at the sending entity from various base stations. In some examples, the sending entity can be a TSN - AF, and each base station is integrated into the TSN system as a TSN bridge by a method according to the present disclosure.

[0062] As shown in block 203, method 200 includes compiling, by the sending entity, the received base - station - specific QoS parameters into a QoS profile. Such a profile combines the QoS parameters from each of the plurality of base stations. The profile can be in tabular form, for example. The profile can be in list form, for example.

[0063] As shown in block 204, method 200 further includes sending, by the sending entity, the QoS profile to a control entity. The control entity can be, for example, a control entity of a centralized network architecture. The control entity can be connected to different sending entities, and each sending entity operates according to a method such as method 200. In some examples, the control entity is a CNC node of the TSN network.

[0064] Figure 3 Illustrates an example apparatus 300 including a processor 301, a memory 302, and a networking module 303. The processor 301 is configured to operate according to any of the methods described herein. In some examples, apparatus 300 is a base station. In some examples, apparatus 300 is a sending entity. In some examples, apparatus 300 is a control entity. The processor 301 can include electronic circuitry for computation managed by an operating system.

[0065] Figure 3 Also illustrates a non - transitory machine - readable or computer - readable storage medium, such as, for example, a memory or storage unit 302, where the non - transitory machine - readable storage medium is encoded with instructions 304 executable by a processor such as processor 301. The machine - readable storage medium includes instructions 304 to operate the processor 301 to perform according to any of the example methods described herein.

[0066] A computer-readable storage device according to the present disclosure can be any electronic, magnetic, optical, or other physical storage device that stores executable instructions. The computer-readable storage device can be, for example, a random access memory (RAM), an electrically erasable programmable read-only memory (EEPROM), a storage drive, and an optical disc, etc. As described herein, the computer-readable storage device can be encoded with executable instructions according to the methods described herein.

[0067] The storage device or memory can include any electronic, magnetic, optical, or other physical storage device that stores executable instructions as described herein.

[0068] In some further examples described below, the method, apparatus, or computer-readable storage device according to the present disclosure is used to integrate a 5G communication system (5GS) into the framework of a time-sensitive network (TSN) in the field of, for example, a wireless industrial communication system.

[0069] The TSN network can include a TDMA (Time Division Multiple Access)-based wired Ethernet network that relies on the IEEE 802.1 TSN standard. The TSN communication system can rely on a high-precision synchronization protocol shared among the nodes of the network defined in IEEE802.1AS. The component of the TSN system is a time-aware packet traffic shaper (TAS) for the timely transmission of TSN packets and jitter reduction. As an Ethernet network, the TSN network can be formed by end nodes (speaker / listener nodes) and bridge nodes connected between the end nodes through bidirectional Ethernet links. For the TSN network, three example architecture alternatives are possible: a centralized architecture; a fully distributed architecture; and a network centralized and user distributed model.

[0070] In the TSN centralized architecture, as Figure 4 shown, the terminal station is sending a flow requirement and TSN communication configuration to the centralized user configuration system (CUC). The CUC transmits the user configuration to the centralized network configuration node (CNC). Each TSN switch identifies the CNC as a delay management object. For example, the example parameters transmitted by the switch to the TSN are the egress and ingress port identifiers, traffic class, and QoS parameters, such as the minimum and maximum delays for each port pair. The CNC can calculate a schedule that includes, for example, the transmission time of the switch between TSN terminal stations, the control parameters of the TAS of different switches, and a routing decision, i.e., switch selection. Such calculations can be performed to meet the flow requirements of TSN communication.

[0071] In the example, the 5G system is considered a TSN bridge that receives timing and control information from the CNC through the TSN-AF, as Figure 5As shown. The TSN-AF converts the control information and sends it to the Policy Control Function (PCF), which defines the profile of the Packet Data Unit (PDU) session to be implemented by the Session Management Function (SMF) and the Access and Mobility Management Function (AMF). According to the CNC timing schedule, this profile can aim to propagate TSN packets (regarded as logical TSN bridges) in the network to the TSN end stations. In this example, the 5GS architecture is in Figure 6 shown.

[0072] Refer to Figure 6 , the user plane of the TSN converter engine is converting the protocol from TSN to GTP-U packets (example General Packet Radio Service GPRS Tunneling Protocol) via the N60 interface (for uplink TSN transmission), or to packets to be sent through the 5G system, such as via the N3 and Uu interfaces for downlink TSN transmission. The control plane of the TSN converter engine (AF) is mapping the TSN control information from the CNC to QoS profile information, which is sent to the Policy Control Function (PCF). If the PCF agrees and the 5GS can meet the requested QoS from the TSN system, a PDU session is established using the 5G QoS Indicator (5QI). In this example, two hold-and-forward buffers are used for dejittering of TSN transmission, one at the user plane TSN converter (NW-TT) for uplink transmission or at the device TSN converter (DS-TT) for downlink transmission, in order to minimize or reduce jitter and resynchronize the packets leaving the UPF (User Plane Function) and the UE (User Equipment). At the Radio Access Network (RAN) level, various techniques can be used to reduce latency and increase the reliability of the transmission of the TSN PDU session. Time-Sensitive Communication Assistance Information (TSCAI) including the following information can be used for the quality of service control of TSN flows in the network:

[0073] - Flow direction: The direction of the TSC (Time-Sensitive Communication) flow (uplink or downlink)

[0074] - Period: Refers to the time period between the starts of two consecutive bursts

[0075] - Burst arrival time: The arrival time of the data burst at the entrance of the RAN (Radio Access Network or base station) (downlink flow direction) or at the exit interface of the UE (uplink flow direction).

[0076] In this example, the information is provided by the Session Management Function (SMF) based on information received from the PCF as a QoS flow profile implemented by the RAN (or base station). The RAN may implement a specific scheduling scheme, e.g., a grant-based scheduling configured with K-repetition transmission of packets. Additional mechanisms may be used to limit the latency at the MAC (Media Access Control) / RLC (Radio Link Control) / PDCP (Packet Data Convergence Protocol) layers in order to account for the TSCAI used to determine the sizes of the RLC and PDCP buffers at the base station and at the UE with TSN capabilities. To configure the scheduling of the TSN network, according to the method described herein, the CNC receives parameters from the 5G system, which helps the CNC identify the scheduling for transmission from a TSN speaker to a TSN listener via the 5GS. For this purpose, the 5GS may expose two latency characteristics to the CNC, such as the minimum end-to-end latency and the maximum end-to-end latency for various TSN flows and for each TSN-capable user terminal's transmission. According to the example method, such latency characteristics may be included in the QoS parameters. The method described herein enables reliance on, e.g., the learning capabilities of the NG-RAN node base station. Such a method helps increase scalability and reduce the latency of the overall initial configuration of the 5GS acting as a bridge to the TSN network by avoiding an alternative method of iterative trial and error learning of network configuration and performance capabilities via the TSN application function, which may be less scalable and more time-consuming.

[0077] During an example initial configuration of the 5G system acting as a TSN bridge according to the example method, it is proposed to add a new QoS_query message to the 5GS signaling between the 5G core network and the NG-RAN. This QoS_query message corresponds to a QoS parameter request according to the present disclosure in this example. The QoS_query message triggers the QoS parameter determination process at the NG-RAN base station. The NG-RAN base station, for example, estimates its capabilities, i.e., the performance parameters (e.g., latency, throughput) at which the base station is positioned to provide the provided topology, taking into account, e.g., the number of UEs, the scheduling algorithm, radio interference, and radio channel statistics, and provides them in the form of descriptors for one or more sessions. In this example, the interface between the 5GS bridge and the TSN system is not affected. This example is illustrated in Figure 7 where, in this case, a given topology configured in the form of a flow or the communication service of a session conveyed in a session descriptor is part of a QoS parameter request (or QoS query request), and the parameters (in this case the minimum latency and the maximum latency) are determined or evaluated by the base station and sent as a QoS query response corresponding to the determined QoS parameters, and then the thus determined QoS parameters are exposed or sent to the CNC.

[0078] In this example, the method according to the present disclosure can be considered a bottom-up method, i.e., the 5GS base station notifies the CNC. The relevant network parameters for integrating the 5G system with the TSN are actually determined actively in the radio access network and sent to the application function by means of a QoS query (or QoS parameter request) procedure. The UE, which is part of the 5GS bridge, can first register in the 5GS network. The TSN-AF can select a UPF for the set of UEs and establish a PDU session. This defines a given topology for the 5GS bridge, i.e., it defines the set of port numbers, port addresses, and packet forwarding rules from the UE to the selected user plane function corresponding to the PDU session. The QoS query request triggers the process of determining performance parameters by the NG-RAN node, as shown in Figure 8 as shown. The QoS query response message is used to send the performance parameters or the determined QoS parameters to the TSN application function and / or expose the relevant network parameters to the CNC through the Network Exposure Function (NEF) for the CNC's scheduling calculation. In this case, the 5GS bridge capabilities (in terms of QoS performance parameters) for a given topology can be determined quickly and circular attempts can be avoided. The scheduler in the NG-RAN node is the entity that determines the QoS support on the radio link in this example. The NG-RAN base station actually has the advantage of knowing the constraints and capabilities of the radio link. This process can be applied as a whole to a given topology (or session configuration). The capability determination (or QoS parameter determination) can consider the UE-to-UE interference, statistics, or prediction of the radio channel conditions by the base station. The session management function can efficiently use the capability determination (or QoS parameter determination) to actively determine the packet routing and forwarding rules at the UPF in order to adapt to the NG-RAN capabilities and incorporate the bridge capabilities.

[0079] As Figure 8 shown, in the first step, the initial configuration of the session is performed. In this case, this step is performed between the TSN application function (TSN-AF), the Access and Mobility Management Function (AMF), the Session Management Function (SMF), and the Radio Access Network (NG-RAN). The configuration includes, for example, determining a PDU session between one or more UEs with TSN capabilities and one or more UPFs.

[0080] In this case, the QoS parameter request refers to a special session called a "probe" session. This can be done by including a special QoS flow indicator (or an indication that the session is a probe session) in the request, which means that the PDU session is intended for QoS probing. Therefore, the base station does not have to reserve resources for the communication flow.

[0081] In this example, the QoS parameter request may indicate PDU probing session requirements (or QoS parameter determination constraints), e.g., throughput, latency, or priority. In addition to this, the QoS parameter request includes a probing indication (or indication that one or more sessions are probing sessions), which is common for a PDU session or for each QoS parameter (e.g., latency-based probing). In some examples, the probing session is related to a given target throughput and a given packet size as QoS parameter determination constraints, and as a probe of latency as a QoS parameter, to be determined by the base station for the constraints. Then, the base station may estimate or determine the latency that the base station can support for the flow (QoS parameter determined in this case), and / or provide a latency range or interval around the value of the QoS parameter that the base station estimates it can support, determined to be for the probing session.

[0082] In the example, the QoS parameter request may include:

[0083] - Guaranteed Bit Rate (GBR) = n bits / s (given as a parameter determination constraint)

[0084] - Latency = y ms (given as a target in milliseconds)

[0085] - Probe of latency (as a QoS parameter to be determined)

[0086] In this example, the session parameter request estimates the minimum and maximum latency that, for example, a GBR flow of n bits / s can achieve. Note that in this example, a target latency is indicated. The base station may ignore the target latency for its estimate, or the target indication may not exist. The base station may also consider target information such as the target latency to select appropriate resources (since this is a probing session rather than an active session, such selected resources are not actually used for this purpose).

[0087] In this example, the probing indication or indicator that the session is a probing session may be used by the base station to modify the base station session access control. For example, in the case of probing, the base station may accept all requested probing sessions, due to the fact that such sessions are for probing purposes and do not affect the active current sessions at the base station. In fact, in non-probing cases, the base station accepts the session including the given QoS requirements only if it estimates that it has sufficient resources and capabilities to handle the session. However, in a probing context, the base station may accept a given probing session configuration regardless of the current resource usage, to provide back an estimate of the QoS that it can support for the session. The base station may actually consider different scheduling parameters and / or static HARQ or other physical layer parameters in the case of probing according to examples of the present disclosure, in order to determine relevant performance parameters (or QoS parameters) for various physical layer configurations.

[0088] As shown Figure 8 in FIG. 2, the TSN-AF sends a QoS query request message (corresponding to a QoS parameter request) to trigger QoS probing (corresponding to determining QoS parameters) at the NG-RAN base station based on the session parameters configured in the previous step. The message may include:

[0089] - A list of session identifiers that topologically constitute the probe; and

[0090] - An indication of the parameters that must be estimated or determined, e.g., minimum delay and maximum delay. In the sense that the probe is not performed on a specific session but on the topology (i.e., on the set of sessions and the corresponding NG-RAN parameters), the message is non-UE specific.

[0091] This allows the determination of the capabilities (or QoS parameters) corresponding to a given topology of the probe session, taking into account the resource sharing policy between different sessions. In this case, the QoS query request also includes a flag parameter or ProbingFlag, which indicates how the probe request interacts with the current active (non-probe) sessions. If the flag is set to "add", the base station determines the QoS parameters for the sessions identified in the session identifier list in addition to the currently ongoing sessions. If the flag is set to "replace", the base station determines the QoS parameters for the sessions identified in the session identifier list without considering the currently ongoing sessions, i.e., as if all resources were available. In both cases, the ongoing sessions are not actually affected, which means that the QoS query request can be performed online, i.e., the traffic does not have to be stopped. "Replace" can be used as a probe flag to evaluate what the overall impact would be of adding new flows or sessions. "Replace" can also be used to test what the switching capabilities would be in the case where an ongoing flow or session is removed.

[0092] As shown Figure 8As shown, when receiving a QoS query request message, the base station determines the required QoS parameters defined in the session description and / or in the QoS request message. For example, the base station estimates the minimum and maximum delays that the base station will be able to support for each session. For example, the base station can perform its estimation by establishing resource reservation plans for different sessions, knowing the physical layer configuration, the available radio resources, and the estimation of the radio channel conditions. The base station can estimate the possible resource configurations based on the deployment topology received in the initial flow configuration step and determine the QoS parameters as average values. The base station can estimate the possible resource configurations based on the deployment topology received in the initial flow configuration step and determine the QoS parameters as worst-case values. In some cases, the base station estimates the QoS parameters based on a given session configuration, whereby such a configuration remains stable during the probing, i.e., during the period including the corresponding freeze / thaw actions, no session should be established or released. In this case, after the configuration is frozen, the base station rejects session establishment, modification, or release until the configuration is thawed.

[0093] As Figure 8 shown, the QoS parameters estimated or determined are sent in the QoS query response message to the TSN-AF for each probing session. These parameters are indicated in the QoS query request message.

[0094] As Figure 8 shown, the TSN-AF receives in the QoS query response message the estimated network capabilities as the QoS parameter values of the QoS parameters and incorporates such QoS parameter values in the QoS profile, for example, by mapping these values to the topology sent during the initial flow configuration. These parameters may come from several base stations (according to Figure 8 , several NG-RANs). Each such base station can be exposed to the CNC of the TSN system as part of the per-port parameters of the 5GS bridge.

[0095] The exemplary method according to the present disclosure can occur between the CN (core network) and the RAN (base station). The exemplary method according to the present disclosure can also be used between the functions of the CN to trigger and estimate the QoS parameters along the data plane paths between the RAN and the CN and within the CN.

[0096] In some examples, the probing parameters in the QoS query message or the content of the QoS parameter request can be different, or can change between the TSN-AF and the SMF, between the SMF and the AMF, and between the AMF and the NG-RAN. The SMF can, for example, intercept the QoS query response, extract the relevant QoS parameters, and use these QoS parameters for the selection and update of the user plane function (UPF) topology. Such modification of the QoS parameter request by an intermediate entity such as the SMF can be via an additional container in the message from the SMF to the UPF. Such a selection can be based, for example, on:

[0097] - The selection of the UPF can introduce a minimum latency and jitter for the expected TSN transmission.

[0098] - Updating the packet forwarding rule (FAR) based on the received QoS information from the QoS query response message, where the SMF maintains the UPF capabilities and sends the updated version of the FAR to the UPF.

[0099] - Updating the QoS enforcement rule (QER) provided by the SMF to the UPF, where the SMF maintains the UPF capabilities and sends the updated version of the QER to the UPF.

[0100] A specific session can be configured to probe for QoS parameters in the core network (i.e., at the interface between the NG-RAN and the UPF). These specific sessions or PDU sessions can be used to further probe the N4 interface based on the QoS_Query_response message.

[0101] In some examples, when the QoS parameters are determined, the probing session is removed.

[0102] Another example of the method according to the present disclosure is illustrated in Figure 9 where a list of session descriptions described by the probing session is directly included in the query request message as a session descriptor, rather than using, for example, the session identifier in the session descriptor according to Figure 8 the example. In this example according to Figure 9 the PDU session can refer to a specific UE, and each session description in the list includes an identifier of the specific UE in addition to including QoS parameters. Between the AMF and the NG-RAN, this can be done, for example, by a specific identifier referring to the reference UE context in the base station and a session identifier between the functions of the core network (SMF, AMF).

Claims

1. A method for determining Quality of Service (QoS) parameters, the method comprising the following steps: - Receiving, at a base station, a QoS parameter request for a session from a sending entity, wherein the request includes a descriptor of the session and an indication that the session is a probe session, the probe session being different from a session that should be effectively established for effectively sending or receiving data; - Determining, at the base station, the QoS parameters associated with the probe session; and - Sending, by the base station, the determined QoS parameters to a receiving entity.

2. The method according to claim 1, wherein, The sending entity and the receiving entity are the same entity.

3. The method according to claim 2, wherein, The entity is a Time-Sensitive Networking Application Function (TSN-AF) entity.

4. The method according to any one of claims 1 - 3, wherein The request includes multiple messages.

5. The method according to any one of claims 1-3, wherein As an action related to the request, the base station does not reserve resources.

6. The method according to any one of claims 1 to 3, wherein The QoS parameter request includes a QoS parameter determination context, wherein the QoS parameter determination context includes both parameter determination constraints and an indication of the type of QoS parameter determined within the parameter determination constraints.

7. The method according to claim 6, wherein, The parameter determination constraints include one or more of a maximum bit rate, a priority, or a packet error rate, and wherein the type of QoS parameter determined within the parameter determination constraints includes delay information.

8. The method according to any one of claims 1-3, wherein, The request includes a probe flag, the probe flag indicating that the probe session is to be considered as replacing the current active session at the base station, or the probe flag indicating that the probe session is to be considered in addition to the current active session at the base station.

9. The method according to any one of claims 1-3, wherein, The step of determining, at the base station, the QoS parameters associated with the probe session includes: establishing, by the base station, a resource reservation plan for the probe session.

10. The method according to any one of claims 1-3, wherein, The step of determining, at the base station, the QoS parameters associated with the probe session includes: preventing the establishment of an active session at the base station and including preventing the release of the current active session at the base station.

11. The method according to any one of claims 1 - 3, wherein, The QoS parameter request is also related to one or more additional sessions, the descriptor is also related to the one or more additional sessions, and the indication also indicates that the one or more additional sessions are one or more additional probe sessions.

12. The method according to claim 11, wherein, The step of determining, at the base station, the QoS parameters associated with the probe session includes: - Determining, at the base station, the QoS parameters associated with one or more additional probe sessions; and - Establishing, by the base station, a resource reservation plan for the probe session and for one or more additional probe sessions.

13. A method for determining Quality of Service (QoS) parameters, the method comprising the following steps: - Sending, by a sending entity, a QoS parameter request for a session to a plurality of base stations, wherein each request includes a descriptor of the session and an indication that the session is a probe session, the probe session being different from a session that should be effectively established for effectively sending or receiving data; - Receiving, at the sending entity, base station-specific QoS parameters associated with the probe session from each of the plurality of base stations; - Compiling, by the sending entity, the received base station-specific QoS parameters into a QoS profile; and - Sending, by the sending entity, the QoS profile to a control entity.

14. A computer-readable storage medium comprising instructions that, when executed by a processor of a computing device, cause the processor to perform the method according to any one of claims 1-13.

15. An apparatus comprising a processor, a memory, and a networking module, the processor being configured to operate according to any one of method claims 1-13.

Images