Patent Description:
<FIG> is a schematic representation of an example of a terrestrial wireless network <NUM> including a core network <NUM> and a radio access network <NUM>. The radio access network <NUM> may include a plurality of base stations gNB<NUM> to gNB<NUM>, each serving a specific area surrounding the base station schematically represented by respective cells <NUM><NUM> to <NUM><NUM>. The base stations are provided to serve users within a cell. The term base station, BS, refers to a gNB in <NUM> networks, an eNB in UMTS/LTE/LTE-A/ LTE-A Pro, or just a BS in other mobile communication standards. A user may be a stationary device or a mobile device. The wireless communication system may also be accessed by mobile or stationary loT devices which connect to a base station or to a user. The mobile devices or the loT devices may include physical devices, ground-based vehicles, such as robots or cars, aerial vehicles, such as manned or unmanned aerial vehicles (UAVs), the latter also referred to as drones, buildings and other items or devices having embedded therein electronics, software, sensors, actuators, or the like as well as network connectivity that enable these devices to collect and exchange data across an existing network infrastructure. <FIG> shows an exemplary view of only five cells; however, the wireless communication system may include more such cells. <FIG> shows two users UE<NUM> and UE<NUM>, also referred to as user equipment, UE, that are in cell <NUM><NUM> and that are served by base station gNB<NUM>. Another user UE<NUM> is shown in cell <NUM><NUM> which is served by base station gNB<NUM>. The arrows <NUM><NUM>, <NUM><NUM> and <NUM><NUM> schematically represent uplink/downlink connections for transmitting data from a user UE<NUM>, UE<NUM> and UE<NUM> to the base stations gNB<NUM>, gNB<NUM> or for transmitting data from the base stations gNB<NUM>, gNB<NUM> to the users UE<NUM>, UE<NUM>, UE<NUM>. Further, <FIG> shows two loT devices <NUM><NUM> and <NUM><NUM> in cell <NUM><NUM>, which may be stationary or mobile devices. The loT device <NUM><NUM> accesses the wireless communication system via the base station gNB<NUM> to receive and transmit data as schematically represented by arrow <NUM><NUM>. The loT device <NUM><NUM> accesses the wireless communication system via the user UE<NUM> as is schematically represented by arrow <NUM><NUM>. The respective base station gNB<NUM> to gNB<NUM> may be connected to the core network <NUM>, e.g. via the S1 interface, via respective backhaul links <NUM><NUM> to <NUM><NUM>, which are schematically represented in <FIG> by the arrows pointing to "core". The core network <NUM> may be connected to one or more external networks. Further, some or all of the respective base station gNB<NUM> to gNB<NUM> may connected, e.g. via the S1 or X2 interface or XN interface in NR, with each other via respective backhaul links <NUM><NUM> to <NUM><NUM>, which are schematically represented in <FIG> by the arrows pointing to "gNBs".

For data transmission a physical resource grid may be used. The physical resource grid may comprise a set of resource elements to which various physical channels and physical signals are mapped. For example, the physical channels may include the physical downlink and uplink shared channels (PDSCH, PUSCH) carrying user specific data, also referred to as downlink and uplink payload data, the physical broadcast channel (PBCH) carrying for example a master information block (MIB) and a system information block (SIB), the physical downlink and uplink control channels (PDCCH, PUCCH) carrying for example the downlink control information (DCI). For the uplink, the physical channels may further include the physical random access channel (PRACH or RACH) used by UEs for accessing the network once a UE synchronized and obtained the MIB and SIB. The physical signals may comprise reference signals or symbols (RS), synchronization signals and the like. The resource grid may comprise a frame or radio frame having a certain duration in the time domain and having a given bandwidth in the frequency domain. The frame may have a certain number of subframes of a predefined length. Each subframe may include two slots of <NUM> or <NUM> OFDM symbols depending on the cyclic prefix (CP) length. A frame may also consist of a smaller number of OFDM symbols, e.g. when utilizing shortened transmission time intervals (sTTI) or a mini-slot/non-slot-based frame structure comprising just a few OFDM symbols.

The wireless communication system may be any single-tone or multicarrier system using frequency-division multiplexing, like the orthogonal frequency-division multiplexing (OFDM) system, the orthogonal frequency-division multiple access (OFDMA) system, or any other IFFT-based signal with or without CP, e.g. DFT-s-OFDM. Other waveforms, like non-orthogonal waveforms for multiple access, e.g. filter-bank multicarrier (FBMC), generalized frequency division multiplexing (GFDM) or universal filtered multi carrier (UFMC), may be used. The wireless communication system may operate, e.g., in accordance with the LTE-Advanced pro standard or the <NUM> or NR, New Radio, standard.

The wireless network or communication system depicted in <FIG> may by a heterogeneous network having distinct overlaid networks, e.g., a network of macro cells with each macro cell including a macro base station, like base station gNB<NUM> to gNB<NUM>, and a network of small cell base stations (not shown in <FIG>), like femto or pico base stations.

In addition to the above described terrestrial wireless network also non-terrestrial wireless communication networks exist including spaceborne transceivers, like satellites, and/or airborne transceivers, like unmanned aircraft systems. The non-terrestrial wireless communication network or system may operate in a similar way as the terrestrial system described above with reference to <FIG>, for example in accordance with the LTE-Advanced Pro standard or the <NUM> or NR, New Radio, standard.

A wireless communication network as described above may be used by an application to provide a certain service to a UE in the RAN with a certain Quality of Service, QoS. The QoS may be monitored in the wireless communication network. For example, in LTE the QoS may be determined per Evolved Packet System, EPS, bearer as described in detail in reference [<NUM>], while in NR the QoS may be determined on a per flow basis as is described in detail in reference [<NUM>]. Reference [<NUM>] refers to the Allocation/Retention Priority (ARP), which determines if a pre-allocated resource should be reallocated based on a higher priority service in LTE and NR. The ARP has a range of <NUM>-<NUM> levels and may be described by the pre-emption capability, which defines whether a service data flow may get resources that were already assigned to another service data flow with a lower priority level, and by the pre-emption vulnerability information which defines whether a service data flow may lose the resources assigned to it in order to admit a service data flow with higher priority level. The pre-emption capability and the pre-emption may consist of a 'yes' or 'no' flag depending on the priority of the service as is described in reference [<NUM>]. The ARP may be considered when creating a new EPS bearer in a fully loaded wireless network, i.e., a network currently having insufficient resources. An emergency VoIP call is a typical example, where an existing bearer is removed in the event that an emergency call must be made.

In the context of LTE, the network entities that handle the monitoring and the reporting to an application server in EPS are the Service Capability Exposure Function (SCEF), and the Mobility Management Entity (MME). The 3GPP Architecture for Service Capability Exposure in EPS is described in detail in reference [<NUM>] with reference to Figure <NUM>-<NUM>. The procedure of monitoring event configuration and deletion at the MME/SGSN is also described in detail in reference [<NUM>] with reference to Figure <NUM>.

In the context of NR, the network entities which handle monitoring and reporting to application server in 5GS are the Access and Mobility Management (AMF) and the Network Exposure Function (NEF). The Event Exposure using NEF is described in detail in reference [<NUM>] with reference to Figure <NUM>. <NUM>-<NUM>, and a list of event-based monitoring capabilities and the corresponding network function (NF), which detects the event, is indicated in Table <NUM>. <NUM>-<NUM> of reference [<NUM>].

In mobile communication networks, for example in a network like that described above with reference to <FIG>, like an LTE or <NUM>/NR network, there may be UEs that communicate directly with each other over one or more sidelink (SL) channels, e.g., using the PC5 interface. UEs that communicate directly with each other over the sidelink may include vehicles communicating directly with other vehicles (V2V communication), vehicles communicating with other entities of the wireless communication network (V2X communication), for example roadside entities, like traffic lights, traffic signs, or pedestrians. Other UEs may not be vehicular related UEs and may comprise any of the above-mentioned devices. Such devices may also communicate directly with each other (D2D communication) using the SL channels.

When considering two UEs directly communicating with each other over the sidelink, both UEs may be served by the same base station, i.e., both UEs may be within the coverage area of a base station, like one of the base stations depicted in <FIG>. This is referred to as a "in coverage" scenario. In accordance with other examples, both UEs that communicate over the sidelink may not be served by a base station which is referred to as an "out-of-coverage" scenario. It is noted that "out-of-coverage" does not mean that the two UEs are not within one of the cells depicted in <FIG>, rather, it means that these UEs are not connected to a base station, for example, they are not in an RRC connected state. Yet another scenario is called a "partial coverage" scenario, in accordance with which one of the two UEs which communicate with each other over the sidelink, is served by a base station, while the other UE is not served by the base station.

<FIG> is a schematic representation of a situation in which two UEs directly communicating with each other are both in coverage of a base station. The base station gNB has a coverage area that is schematically represented by the circle <NUM> which, basically, corresponds to the cell schematically represented in <FIG>. The UEs directly communicating with each other include a first vehicle <NUM> and a second vehicle <NUM> both in the coverage area <NUM> of the base station gNB. Both vehicles <NUM>, <NUM> are connected to the base station gNB and, in addition, they are connected directly with each other over the PC5 interface. The scheduling and/or interference management of the V2V traffic is assisted by the gNB via control signaling over the Uu interface, which is the radio interface between the base station and the UEs. The gNB assigns the resources to be used for the V2V communication over the sidelink. This configuration is also referred to as a mode <NUM> configuration.

<FIG> is a schematic representation of a situation in which the UEs are not in coverage of a base station, i.e., the respective UEs directly communicating with each other are not connected to a base station, although they may be physically within a cell of a wireless communication network. Three vehicles <NUM>, <NUM> and <NUM> are shown directly communicating with each other over a sidelink, e.g., using the PC5 interface. The scheduling and/or interference management of the V2V traffic is based on algorithms implemented between the vehicles. This configuration is also referred to as a mode <NUM> configuration. As mentioned above, the scenario in <FIG> which is an out-of-coverage scenario does not mean that the respective mode <NUM> UEs are outside of the coverage <NUM> of a base station, rather, it means that the respective mode <NUM> UEs are not served by a base station or are not connected to the base station of the coverage area. Thus, there may be situations in which, within the coverage area <NUM> shown in <FIG>, in addition to the mode <NUM> UEs <NUM>, <NUM> also mode <NUM> UEs <NUM>, <NUM>, <NUM> are present.

When a vertical application, e.g. a V2X application, is run over a cellular network, like a 3GPP EPS or 5GS, information regarding a network situation, e.g. congestion, may help the application to adjust itself to the network capability. The network situation may include the status of the network at the moment and/or the prediction of the status of the network. When considering V2X as an example application, the importance of network status feedback may be explained for various scenarios and use cases.

The benefit and necessity of a network feedback to the application has been recognised for the V2X application in 3GPP standardization:.

In a conventional <NUM> Core Network, 5GC, in case the bit rate of a GBFR (guaranteed flow bit rate) drops below the guaranteed rate, a notification is sent to the application.

Thus, the conventional notification cannot handle network monitoring required by the vertical application such as V2X. In addition to the notification mechanism, in core networks of conventional systems, like EPC and 5GC, there is a mechanism to expose some events or capabilities of the network to the application. However, such network exposure capability functionalities for the reliable and efficient performance of a vertical application such as V2X. Therefore, conventional approaches dealing with the handling of high priority transmissions and the handling of QoS are not sufficient in many situations, like in vehicular scenarios in which limited resources or certain events in the system need to be addressed.

<NPL>, concerns NWDAF-Assisted QoS Profile Provisioning. A procedure to support QoS Profile Provisioning during a PDU Session Modification is described, in which, in case a network condition change occurs at a NG-RAN, a notification control procedure may be initiated to notify an AF that the QoS targets of the QoS Flow cannot be fulfilled.

The PDU Session Modification is described in subclause <NUM>.

The Notification control is described in subclause <NUM>. <NUM> of "<NPL>.

It is noted that the information in the above section is only for enhancing the understanding of the background of the invention and therefore it may contain information that does not form prior art that is already known to a person of ordinary skill in the art.

Starting from the prior art discussed above, it is an objective underlying the present invention to provide improved approaches for a reallocation and reservation of resources for high priority communications, for a QoS feedback and for handling certain events in a wireless communication network.

This object is achieved by a wireless communication system according to claim <NUM>, and by a method according to claim <NUM>.

Embodiments of the present invention are now described in further detail with reference to the accompanying drawings, in which:.

Embodiments of the present invention is now described in more detail with reference to the accompanying drawings in which the same or similar elements have the same reference signs assigned.

3GPP defines several use cases for NR V2X, like vehicle platooning, extended sensors, advanced driving and remote driving. To realize such use cases, the new technologies used in <NUM> NR may be incorporated along with the reuse of existing LTE V2X mechanisms. <NUM> NR networks accommodate multiple numerologies and subcarrier spacings, SCS, so that NR V2X networks may use multiple resource pools bearing different SCS. The selection of the relevant resource pool with a given SCS may depend on the application service requesting for resources to transmit. It is up to the application to decide the expected QoS level from the network depending on the offered service. For example, in LTE, there are <NUM> different levels of priority and reliability that may be assigned to different application services for V2X broadcast services. In an example where an application requests for a high priority, a resource pool numerology with a higher SCS may be selected primarily in order to meet the latency requirements. A base station BS may ensure that it meets the priority and reliability requirements in mode <NUM> operations. NR currently supports the following numerologies:.

The initial vehicle-to-everything, V2X, specification is included in Release <NUM> of the 3GPP standard. The scheduling and assignment of resources is modified according to the V2X requirements, when compared to the original device-to-device, D2D, communication standard. Cellular V2X operates in the above mentioned two configurations from a resource allocation perspective - mode <NUM> and mode <NUM>. V2X UEs operating in mode <NUM> obtain the scheduling information for sidelink, SL, transmissions from the base station, like a BS, an eNB or a gNB, whereas mode <NUM> UEs autonomously carry out the resource selection. The vehicles may also transmit the messages in one of two ways - either in regular intervals over a duration of time, which is called Semi-Persistent Scheduled, SPS, transmissions, or only once at a single instance, called One Shot, OS, transmissions. For each of these transmissions, there are ProSe per packet priority (PPPP) and a ProSe per packet reliability (PPPR) indicators attached to each broadcasted packet, which dictate the level of priority and reliability needed for the said packet from a given application.

Enhanced V2X addresses the achievement of a certain Quality-of-Service, QoS, for a given application service. For example, when a resource pool is highly loaded with traffic, like V2X traffic, meaning there is a high occupancy in the pool, the BS may not be able to provide the expected QoS requirements for a given application, in the case of mode <NUM> SL transmission. In the case of mode <NUM> SL transmission, UEs may allocate resources autonomously, without any guarantee on the QoS requirements.

A problem with conventional implementations is that certain critical applications, especially applications that transmit messages of high priority and demand high reliability, may not be able to function as expected in such a scenario, thereby affecting the performance of the desired service. Also, there is possibility to convey back from the RAN to an application any information that a required QoS cannot be met.

Embodiments of the present invention may be implemented in a wireless communication system as depicted in <FIG>, <FIG> including base stations and users, like mobile terminals or loT devices. <FIG> is a schematic representation of a wireless communication system for communicating information between a transmitter <NUM> and one or more receivers <NUM><NUM> to <NUM>n. The transmitter <NUM> and the receivers <NUM> may communicate via a wireless communication links or channels 304a, 304b, 304c, like a radio link. The transmitter <NUM> may include one or more antennas ANTT or an antenna array having a plurality of antenna elements, a signal processor 300a and a transceiver 300b, coupled with each other. The receivers <NUM> include one or more antennas ANTR or an antenna array having a plurality of antennas, a signal processor 302a<NUM>, 302an, and a transceiver 302b<NUM>, 302bn coupled with each other.

In accordance with an embodiment, as for example also depicted in <FIG>, the transmitter <NUM> may be a base station and the receivers may be UEs. The base station <NUM> and the UEs <NUM> may communicate via respective first wireless communication links 304a and 304b, like a radio link using the Uu interface, while the UEs <NUM> may communicate with each other via a second wireless communication link 304c, like a radio link using the PC5 interface.

In accordance with an embodiment, as for example also depicted in <FIG>, the transmitter <NUM> may be a first UE and the receivers may be further UEs. The first UE <NUM> and the further UEs <NUM> may communicate via respective wireless communication links 304a to 304c, like a radio link using the PC5 interface.

Embodiments of the present invention may be implemented in a wireless communication system as depicted in <FIG>, <FIG> including base stations and users, like mobile terminals or loT devices. <FIG> is a schematic representation of a wireless communication system <NUM> having a core network <NUM> to which an application server <NUM> is connectable. The application server runs an application to provide a certain service to a receiver with a certain Quality of Service, QoS. Further, the system includes a radio access network, RAN, <NUM> coupled to the core network <NUM>, the RAN <NUM> including a plurality of transmitters and receivers. The wireless communication system <NUM> may operate in accordance with the inventive teachings described herein.

Thus, in accordance with embodiments, the communication system provides a path or mechanism or procedure to notify an application that a certain service with a desired QoS can/cannot be fulfilled from a RAN side. For example, in the case where a resource pool is completely occupied by high priority transmissions, the BS may inform the application or application server that, e.g., a required priority and reliability (QoS), cannot be met, so as to allow the application to alter its behavior accordingly, say in the case of a fully autonomous car. The relevant network entities (in LTE) or network functions (in <NUM>) related to the application layer, may subscribe to monitor various changes in QoS related events or RAN events. These events may then be signaled back to the application function.

Embodiments of the third aspect of the present invention may be implemented in a wireless communication system as depicted in <FIG>, <FIG> including base stations and users, like mobile terminals or loT devices. <FIG> is a schematic representation of a wireless communication system <NUM> having a core network <NUM> to which an application server <NUM> is connectable. The application server runs an application to provide a certain service to a receiver with a certain Quality of Service, QoS. Further, the system includes a radio access network, RAN, <NUM> coupled to the core network <NUM>, the RAN <NUM> including a plurality of transmitters and receivers. The wireless communication system <NUM> may operate in accordance with the inventive teachings described herein.

The present invention provides a wireless communication system, comprising.

In accordance with the present invention:.

The following passages disclose optional embodiments of the invention.

In accordance with the present invention, the wireless communication system is configured to obtain the status of the RAN.

In accordance with the present invention, the certain event in the RAN comprises one or more of.

In accordance with the present invention, the core network is configured to.

In accordance with the present invention, the RAN is configured to.

In accordance with the present invention, the RAN comprises one or more base stations, gNBs, for serving respective UEs, the gNB configured to collect and process the data related to the status of the cell served by the gNB, and to signal and/or report the status report and/or event/s to the core network.

In accordance with the present invention, the gNB is configured to collect and process data related to the status of one or more cells served by other gNBs.

In accordance with the present invention, the RAN comprises one or more base stations, gNBs, for serving respective UEs, the gNB configured to collect the data related to the status of the cell served by the gNB, and to signal the data to the NWDAF, through network functions (NFs) such as access and mobility function (AMF) and/or session management function (SMF).

In accordance with the present invention, the RAN comprises one or more base stations, gNBs, for serving respective UEs, the gNB configured to collect and process the data related to the status of the cell served by the gNB, and to signal and/or report the status report and/or event/s to the application and/or to the receiver running the service provided by the application.

In accordance with the present invention, the status report includes one or more of the following:.

As part of the claimed invention, the status report includes QoS requirements achievable in the RAN.

In accordance with the present invention, the wireless communication system is configured to report that the certain QoS can be fulfilled or cannot be fulfilled responsive to the application request from the core network for a report on QoS or another RAN measure causing a change in achievable QoS.

In accordance with the present invention, the event includes a change in the RAN and/or network, e.g. congestion in the RAN, overload in the RAN, a degradation or improvement is supportable QoS.

In accordance with the present invention, the wireless communication system is configured to signal that the certain QoS can be fulfilled or cannot be fulfilled responsive to the application subscribing to a notification from the core network for a QoS change or another RAN events causing a change in achievable QoS.

In accordance with the present invention, the inventive wireless communication system comprises:.

Thus, in accordance with embodiments of the third aspect, the communication system provides a path or mechanism or procedure to notify an application that a certain service with a desired QoS can/cannot be fulfilled from a RAN side. For example, in the case where a resource pool is completely occupied by high priority transmissions, the BS may inform the application or application server that, e.g., a required priority and reliability (QoS), cannot be met, so as to allow the application to alter its behavior accordingly, say in the case of a fully autonomous car. The relevant network entities (in LTE) or network functions (in <NUM>) related to the application layer, may subscribe to monitor various changes in QoS related events or RAN events. These events may then be signaled back to the application function.

Non-claimed embodiments will now be described in more detail. In the following reference is made to a resource pool. However, the invention is not limited to resource pool, rather the inventive approach is equally applicable to any set of resources. The pool or set of may include a plurality of contiguous or non-contiguous resources across a frequency domain and adjacent or non-adjacent across a time domain. Thus, when referring in this specification to a resource pool this to be understood also as a reference to a set of resources.

Examples of the first aspect, which are not encompassed by the wording of the claims but are considered as useful for understanding the invention, will now be described with reference to <FIG> and <FIG>, of which <FIG> illustrates the pausing of a transmission for freeing or releasing resources to be used for services with higher priority. For the following description, it is assumed that the transmitter <NUM> of <FIG> is a base station, and the receivers <NUM> are UEs, which may or may not communicate also directly with each other over a sidelink 304c. In the latter case, the UEs may be V2X mode <NUM> UEs (see <FIG>).

<FIG>, schematically, illustrates a resource pool <NUM> including a plurality of resources <NUM>, and the resource pool <NUM> is illustrated at different points in time, namely at a time t<NUM>, at a later time t<NUM>, e.g., <NUM> after the time t<NUM>, and at time t<NUM> following t<NUM>, e.g., <NUM> after the time t<NUM>. It is assumed that the resource pool <NUM> includes columns <NUM>-<NUM> and rows <NUM>-<NUM> and, for a communication from the base station <NUM> towards the UE <NUM>, the resources in row <NUM> and the resources in row <NUM> of the resource pool <NUM> are available. At the time t<NUM>, the base station <NUM> performs an initial allocation of the resources for a transmission to the UE <NUM>, for the next <NUM>. It is assumed that resources for two messages need to be allocated, and the messages are assumed to be of substantially the same priority, at least none of them requires a high priority transmission. For example, the first transmission has allocated two resources, the resources in column <NUM>, row <NUM> and in column <NUM>, row <NUM>, as is indicated by the cross-hatched blocks, and the second transmission has allocated three resources, namely the resources in column <NUM>, row <NUM>, in column <NUM>, row <NUM> and in column <NUM>, row <NUM>, as is indicated by the hatched blocks. Thus, in the depicted example only one resource at column <NUM>, row <NUM> remains non-allocated.

At the time t<NUM>, the base station <NUM> receives a request for a transmission of a high priority message that needs to be signaled with low latency to the UE <NUM><NUM>. It is assumed that three resources are needed for the high priority transmission, however, at this time, all resources, except for one resource, for a transmission to the UE <NUM><NUM>, are occupied, so that there are not sufficient resources available in the pool for the high priority transmission. Therefore, in accordance with the present invention, the base station determines, for example, which of the currently transmitted messages has the lowest priority, e.g., the first message. The base station releases the resources associated with the second transmission (see the crossed-out resources in <FIG>) thereby freeing resources in column <NUM>, row <NUM>, column <NUM>, row <NUM> and column <NUM>, row <NUM> of the resource pool <NUM>. At the next possible time, like time t<NUM>, a resource allocation is carried out, so as to fully or at least partly allocate to the high priority transmission the released resources, as is indicated by the black boxes. The newly allocated resources at time t<NUM> may be used for a downlink transmission of the high priority message from the base station <NUM> to the UE <NUM><NUM>, or for an uplink transmission of the high priority message from the UE <NUM>, to the base station <NUM>. The UE <NUM>, receives from the base station <NUM> a signal indicating that the transmission of the second transmission need to be stopped or paused because there are not sufficient resources in the pool for the high priority transmission so that the already allocated resources for the first transmission are released. The UE <NUM>, may either discard the first transmission or resume transmission at a later time, triggered by a preconfigured timer or signaled time value via RRC message or relayed via sidelink by another UE, once the high priority transmission is completed.

In accordance with other examples, in case the UEs also communicate via the sidelink interface, like the PC5 interface 304c in <FIG>, the resources mentioned above with reference to <FIG> may be resources used for the sidelink communication so that the high priority message may be translated among the UEs <NUM><NUM>, <NUM>n via the PC5 interface 304c using resources obtained by the releasing resources allocated initially to low priority transmission on the sidelink in way as described above.

In the example described above, it has been assumed that the high priority message is a downlink message towards the UEs so that the base station may receive a signaling, e.g., from an application running on an application server coupled to the core network of the wireless communication system. On the other hand, the signaling may also be received from a UE, in case a service or application running on the UE which requires a high priority uplink message to be transmitted to the base station. The apparatus may also be a UE communicating with anther UE via a sidelink interface, and either one of the UEs may receive from an associated service or application an indication or signaling that a high priority message is to be transmitted over the sidelink which requires releasing resources of an already scheduled or ongoing lower priority transmission.

In accordance with examples, stopping the lower priority transmission may include pausing the transmission for a predefined time or interval and resuming the transmission after the interval which has been selected so as to make sure that the higher priority transmission is securely accommodated. The first transmission may be resumed using the same configuration as before, or using a new configuration that may be selected from a list of existing configurations or that may be a new configuration provided for resuming the low priority transmission.

In accordance with examples, a plurality of resource pools may be provided, for example a higher priority resource pool having a higher subcarrier spacing, SCS. For example, there may be eight levels of reliability in the context of LTE (PPPR), and in NR there are 5QI or VQI indicators. Messages related to the highest three levels of priority may be associated with resources in a <NUM>-SCS-resource pool which may be referred to as a high priority/low latency resource pool which is selected from a set of available resource pools for a transmission. In case the resource pool, namely the high priority/low priority resource pool is completely congested, the base station is not in a position to allocate any resources for a new transmission to allocate any resources for a new transmission, either over a sidelink between two UEs or over a link between the base station and one of the UEs. On the other hand, due to the low latency and/or high reliability and/or quota requirement of a high priority message, the BS may not reject any transmission of the highest priority, for example due to a safety critical nature of the message, like an emergency call or the like. In other words, high priority message may have a certain latency, reliability, and quota, like a data rate requirement, or any combination of these requirements. In this case, in accordance with the inventive approach, as explained above, the base station which has already sent out grants for a transmission of lower priority to UEs, like SPS transmissions, at the time t<NUM>, when the resources were available, and in case the duration of the grant has not yet elapsed, the BS may withdraw the resources allocated for transmissions of lower priority in favor of transmissions of higher priority. In case multiple resource pools of different priority levels are provided, the BS may try to reallocate resources for the lower transmission into another resource pool of lower SCS, provided the requirements for the lower priority transmission are still met when using resources from the lower priority pool. In case no further pools are available or a reallocation to a lower priority pool does not meet the requirements of the transmission, the transmission of the lower priority message may be paused until the high priority message transmission has been completed. The reallocation being either done when using a new lower priority resource pool, or when resuming the transmission of the low priority message may be done by sending to the UE a revised or updated SPS configuration based on the resource pool load.

In accordance with examples, the base station may notify the UE transmitting low priority messages based on a buffer status report request from the UE transmitting message of higher priority so that, for example, once the base station knows the amount of resources required for the duration for the transmission of messages of higher priority, the interval during which the UE stops or pauses transmitting the message of lower priority, may be determined. This enables the high priority messages to be transmitted in a highly congested dedicated/shared resource pool. Following the interval, the UE may then resume transmission of the low priority message using the resources it was originally allocated by the base station, or the low priority SPS transmission may be shifted in time using, for example, an offset to enable transmission of high priority messages. It is noted that the high priority messages may either be one shot transmissions or SPS transmissions.

In accordance with examples, in case of sidelink transmission modes a SPS transmission may be used and the base station requests the UE transmitting messages of lower priority to pause or shift the transmission in favor of the high priority transmission to or from the UE. In this scenario, the BS may use a revised SPS configuration with a new parameter stating the pause/shift of the interval, as is illustrated in <FIG> showing an example for a SPS-config Information Element, IE. In accordance with examples, the SPS-config IE, as it is described in reference [<NUM>], is extended by the elements "ToPauseList", "ToResumeList", "ToShiftList" as indicated at <NUM>, <NUM> and <NUM> in <FIG>. The "ToPauseList" indicates the SPS-configuration for the sidelink which has to be paused, the "ToResumeList" indicates which of the available SPS-configurations is used upon resuming the low priority transmission, and the "ToShiftList" indicates the duration for which the transmission of the low priority transmission is paused. In case no "ToResumeList" is indicated, the initial configuration used for the low priority transmission will also be used upon resuming transmission.

Thus, the above-mentioned new parameters referring to the pausing, resuming and shifting allow to accommodate the higher transmissions to be transmitted by the UE towards the BS or another UE, or to be received from the BS or another UE at the UE. The BS configures the UE with a lower priority transmission to resume transmission once the high priority message has been transmitted, e.g., using an RRC connection reconfiguration signaling accordingly, like an RRC reconfiguration message.

In accordance with other examples, the apparatus may be a UE connected to another UE via a sidelink configuration, and the respective UEs are out-of-coverage and operating in mode <NUM>, as is explained with reference to <FIG>. The base station, therefore, does not have any control over the resource allocation, however, also in such scenarios a highly congested mode <NUM> resource pool needs to be handled so as to allow low priority transmissions to make way for high priority transmissions. The UE may scan and sense the resource pool for available resources and select them based on the lowest probability of collisions. In the event that the resource pool has not sufficient resources for the high priority transmission, e.g., it is completely occupied, and a UE broadcasts a SCI stating that there is a message of high priority, the SCI will also state the resource which the high priority message uses for the transmission, for example based on a decision of the UE after scanning and sensing the resource pool and choosing a resource having the lowest probability of collision. The inventive approach will be applied, for example, if despite the above-mentioned processes the resource having the lowest probability of collision does not resolve the problem of the congested resource pool. To increase the reliability of the high priority message being received and to reduce the risk of collisions, the UEs that are occupying the selected resource are signaled so as to break or pause their transmission on the resources indicated in the SI for the duration also indicated in the SCI so as to allow the high priority transmission. This ensures that the high priority transmission occurs uninterrupted and upon completion, the UE transmitting a message of lower priority may resume transmission using the initially used resources, for example.

In any of the above-referenced scenarios, the lower priority messages, transmission of which may be paused, may be stored in a buffer of the apparatus or entity which performs the transmission, like a UE. However, there may be situations in which after the completion of the transmission of the high priority message, it is no longer desired or possible to transmit the low priority message, and in such a situation, it will be flushed from the buffer. For example, in case of moving entities, for example vehicles, if the communication arranged between the vehicles has exceeded a maximum communication range, the low priority message will be flushed. For example, if a low priority message transmitting vehicle UE has travelled a certain distance, like <NUM> from the receiving vehicle UE any information of low priority concerning, for example, the immediate surroundings of the sending vehicle are of no more interest for the receiving vehicle which is now at a far distance away. Alternatively, if the higher priority message has exceeded a timer, the buffer of the vehicle UE sending the low priority message may also be flushed.

In accordance with examples of a second aspect, which are not encompassed by the wording of the claims but are considered as useful for understanding the invention,, another approach for addressing the problem of enabling transmissions of high priority is to reserve a small set of resources in the resource pool that is then provided only for the high priority transmissions. <FIG> illustrates schematically an example of the second aspect, and for communication among respective network entities in the radio access network, like between a base station BS and one or more UEs, the pool <NUM> of resources available for communication between the BS and the UEs is shown at a time t<NUM>. It is assumed that at this time only <NUM>% of the resources are used or scheduled, so that any incoming high priority message to be transmitted either from the BS to the UE, from the UE to the BS or among a plurality of UEs may be allocated sufficient resources for the transmission.

At a later time, like time t<NUM> shown in <FIG>, traffic in the cell covered by the base station BS may have increased and it is determined that <NUM>% of the resources of the pool <NUM> are now used. In such a scenario, i.e., once the threshold of <NUM>% has been reached, the allocation of resources to messages of low priority is stopped, and the remaining, unused resources are only allocated to high priority messages. When the threshold drops again, the system may return into the situation as indicated at time t<NUM>, i.e., any of the resources available may be allocated to any message. In a situation as indicated at time t<NUM>, in case a plurality of resource pools of different SCS are available, the low priority message for which no resources will be allocated due to the occupancy level of the first resource pool <NUM>, may have allocated resources from a further resource pool of lower SCS, provided that the requirements of the transmission to be made may be met using the resources from the lower SCS resource pool.

Thus, in accordance with the second aspect, at the time of an increasing occupancy or traffic and a corresponding decreasing number of available resources, the small set of resources now reserved balances the trade-off regarding the amount of data to be transmitted and the available resources to transmit.

It is noted that the above aspect may also be used in a direct communication between two UEs via a sidelink in which the UEs are either in mode <NUM> or in mode <NUM>.

As has been mentioned above, the conventional approaches dealing the handling of QoS are not sufficient in many situations, like in vehicular scenarios. When a vertical application, for example a V2X application, is run over a cellular network as described above, a 3GPP EPS or a 5GS network, it is desired to obtain information about the network situation, like the congestion so as to allow the application to adjust itself to the current network situation or capability. The network situation or capability may include the status or the capability of the network at a current time and/or a prediction thereof for the future. When considering, for example, V2X, the need of a feedback from the network to the application has been recognized by the present invention. Examples of functionalities that may be needed for the reliable and efficient performance of a vertical application such as V2X, are one or more of:.

In accordance with the present invention, a mechanism is provided which obtains a status of at least a part of the RAN, and informs the application and/or the receiver running the service provided by the application about the RAN status and/or any changes of the RAN status, wherein a performance of the service, like the QoS, depends on the RAN status. This allows the application at the UE and/or at the application server to accordingly correct its expectations/requirements. Thus, as the network provides feedback to the UE stating that it cannot manage the requirements requested, the UE's application may alter accordingly. For example, information about a congestion and overload is obtained, in other words, the RAN status with regard to the available resources is monitored. On the basis of this information, the quality of service that may be provided via the RAN, for example using a PC5 interface, may be monitored, or, stated more generally, the status of the link between the communicating entities, for example, the status of a sidelink in terms of resources available for transmissions may be monitored. For example, in case of a certain event, the application server or the UE running an application may react responsive to a corresponding feedback. In some application/services the delay that is induced by this process may be critical. For example in case of a platooning service in a V2X application, when the network is able to provide a high QoS to the service, the server may reduce the distance between platoon members to decrease energy consumption. If the QoS degrades suddenly, the distance between platoon members may need to be increased immediately for safety reasons. Another example is the case of automatic driving. In case the coverage of network degrades, the application needs to react promptly, e.g., to decrease the level of automation and transfer the control to manual mode.

For example, the status may be obtained when a current cells status changes, before/during a handover from between cells, macro cells, small cells or macro cell/small cell.

Although conventional approaches may monitor events related to a link between a UE and the network, for example the location of the UE, the UE reachability, a loss of connectivity, a communication failure or a number of UEs which are present in a specific geographical area, the situation or status of the RAN is actually not monitored, for example, a congestion or overload is not monitored by the core network. Thus, also the resources in the RAN or the achievable QoS is not monitored. In accordance with the the present invention, this gap is closed.

<FIG> illustrates an embodiment for monitoring a RAN situation, and illustrates schematically the respective network entities in an EPS system (see also reference [<NUM>]) including the application server <NUM> coupled to the core network <NUM> which, in turn, is coupled to the radio access network, RAN, <NUM>. The core network includes the service capability exposure function, SCEF 310a, the home subscriber server, HSS, 310b, and the mobility management entity, MME/the serving GPRS support node, SGSN, 312c. The application server <NUM> may run one or more applications via the cellular network <NUM>, <NUM> and issue a monitoring request at step <NUM> which is handled by the SCEF 310a, as is indicated at step <NUM>. The SCEF handling may include a communication with the HSS 310b for an external group ID resolution, as is indicated at steps 2a and 2b. Responsive to the receiving the monitoring request, the SCEF sends a monitoring request at step <NUM> which is handled by the MME 402e as is indicated at step <NUM>. As step <NUM> a monitoring response is provided back to the SCEF 310a. So far, the process corresponds to the conventional process described in reference [<NUM>].

In accordance with embodiments of the present invention, the conventional procedure is extended by steps 4a, 4b and 4c so that the process of monitoring does not stop at the MME 312c but is extended into the RAN <NUM>. The MME 310c signals at step 4a to the RAN <NUM> that certain information from the RAN <NUM> is needed, e.g., information about one or more of the signal traffic load, the resources, the congestion, the interference of some or all UEs of one or more cells of the RAN <NUM>. The RAN <NUM>, at step 4b collects the data, e.g., for creating a RAN status report. At step 4c the RAN status report, which is based on the request at step 4a is provided to the core network <NUM> or is pushed directly to the relevant network entities, like the SCEF 310a, which provides an interface to the application on the server <NUM>. The status report may also be provided to the UE using a service provided by the application. The application, e.g. application server and/or application client and/or the UE, on the basis of the status information, may determine, e.g., whether a desired QoS is still achievable, for example, whether autonomous driving is still possible or whether, due to a reduced QoS an adaption of the service provided by the application is to be carried out, for example in case of autonomous driving, going back to a manual control.

In the following, the inventive concept for obtaining the RAN status will be described with reference to a handover, HO, procedure. However, the inventive approach is not limited to obtaining a RAN status report in such an event, rather, any other event or a signaling from the application may trigger such a report. <FIG> is a signaling chart for a vehicular UE QoS feedback adaptation in accordance with an embodiment of the present invention. More specifically, <FIG> illustrates an embodiment modifying a conventional HO procedure in an EPS system, e.g., in case a predictive HO to multiple target cells is enabled, where the source eNB notifies the UE that the next cell(s)/group of cells can/cannot meet a QoS requirements. Naturally, the inventive approach may be applied to any scenario where the QoS changes within the same cell.

Following step A in which the source gNB makes an evaluating for a possible providing area restriction of the UE with the target gNB, and following step B in which the UE reports measurements, steps C to G are performed as follows:.

Following steps A-G, the further steps <NUM>-<NUM> for completing the HO are performed.

When considering a 5GS, the table below lists the events that are supported by conventional systems.

As this table shows, a situation or status of the resources in the RAN, e.g. RAN congestion and RAN overload cannot be monitored by the application function (AF).

In accordance with further embodiments, the AF is enabled to monitor the RAN events, e.g. RAN congestion and/or overflow. <FIG> illustrates the monitoring of a RAN situation by the application server (AS) <NUM> in 5GC. <FIG> illustrates an embodiment modifying a conventional monitoring procedure to obtain a RAN status.

The 5GS system of <FIG> includes the application server <NUM> connected to the core network <NUM> which, in turn, is connected to the radio access network <NUM>. The core network <NUM> includes the network exposer function, NEF, 310a, the unified data management, UDM, 310b and the core access and mobility management function, AMF, 310c. Conventionally, an application running on the application server, for example a V2X application, subscribes to the core network in step <NUM> so as to obtain the information about certain events in the network. The NEF 310a, at step <NUM>, issues a subscribe request to the UDM 310b which, in turn, issues a subscribe request to the AMF 310c, as indicated at step 3a.

In accordance with the inventive approach, the request sent as steps 3a is also a subscription to obtain information about RAN events, and other than in the conventional approach, the AMF 310c issues at step 3a' a further request to subscribe to a specific RAN event, like resource congestion or overflow. Responsive to the subscription at step 3a', the RAN <NUM> provides respective events subscription response or acknowledgement at step 3b' back to the AMF 310c so that the additional feedback subscription response or acknowledgement about the situation at the RAN <NUM> is provided to the application via the core network <NUM> in steps 3b, <NUM> and <NUM>. In accordance with embodiments, the RAN <NUM> may signals a RAN event to the application server <NUM> via the AMF and the NEF, as indicated at steps <NUM>, <NUM> and <NUM>. For example, <NUM> a report, such as the RPSI event report with reference to the example of <FIG> and/or events described in Table <NUM> may be provided, and the RAN may operate as described above with reference to <FIG> (steps 4b-4c) and <FIG>.

In addition, as in conventional approaches, the application may receive event notification from UDM with or without NEF in the middle via communications at steps 6a and 7a or only a 6a that directly points to the AS. In case of a trusted AS there the NEF between AS and UDM is not needed.

The list of events in the above table is not exhaustive, and further events may be generated and/or collected and/or detected in some other network function (NF), such as the session management function (SMF) and or access and mobility function (AMF). In any case a similar procedure as in <FIG> is provided in accordance with the present invention, and in <FIG> AMF is then replaced by the involved or responsible NF, e.g. SMF.

Thus, the above-embodiments allow applications and/or application functions, AF, to monitor the communication system for certain RAN events related to the resources, for example a RAN congestion and/or overflow, and on the basis of the RAN congestion, overload and the like, i.e., on the basis of the situation of the resources in the RAN, also events can be determined causing a change of the QoS either in the same group or in a different group or cell.

In accordance with yet further embodiments, a network data analysis function may be used for evaluating the information from the RAN so as to determine and/or predict respective events. The NWDAF is responsible for providing network data analytics. NWDAF may for example provide slice congestion events notification and NWDAF operator specific analytics as described in reference [<NUM>]. The NWDAF may be employed as illustrated in <FIG> shows a signaling chart for RPSI processing in a 5GS using the NWDAF. Actually, <FIG> illustrates how the steps for the HO may be performed in the context of the 5GS. The steps A-G correspond to those described above with reference to <FIG>, except that step E is performed in the core <NUM> by the NWDAF.

Thus, according to embodiments, when considering <FIG> or <FIG>, the AF or another part of the system may have information on the UE behavior, e.g., a movement trajectory, and the network may collect additional information about its own situation and about the RAN situation, and provide the result as monitoring event and/or report to the BS, which in turn passes this on to the UE and its residing application and/or application server and/or application client.

When considering <FIG>, other than in <FIG> or <FIG>, the base station provides the information to the network, where it is used by the NWDAF. The NWDAF also receives the information from the RAN and the network. The NWDAF performs an analysis and may provide the result as monitoring event and/or report to the BS, which in turn passes it on to the UE and its residing application and/or application server and/or application client. For example, the NWDAF may do an analysis over data that are provided by the network and by the RAN with or without any info of a UE behavior being provided by the application. In any case, the analysis result provided by the NWDAF may be some prediction.

While aspect <NUM> described above required an application to subscribe so as to obtain a notification for QoS changes and/or RAN events, there may be situations in which it is necessary to inform the application or application function about changing conditions in the overall network.

In accordance with examples of a fourth aspect, which are not encompassed by the wording of the claims but are considered as useful for understanding the invention,, the communication system provides notifications, for example push notifications, to the application server and/or the UE. In other words, the event notifications shown in <FIG> and <FIG> may automatically be triggered so as to inform about critical events or to provide warnings. In other words, in accordance with the fourth aspect, a procedure or mechanism is provided so as to provide the core network with the possibility to generate push notifications which may originate from various sources, like the RAN <NUM>, the network <NUM>, the application, etc. Examples of scenarios where push notifications may be implemented include, but are not limited to, one or more of the following scenarios described with reference to <FIG>.

<FIG> illustrates an example dealing with a critical or severe situation/failure in the RAN, or any other part of the network, for example in case of natural disasters that a part of network is completely down. <FIG> illustrates the cellular network, including the CN and the RAN, to which three application servers AS1 to AS3 are coupled. The cellular network detects an event that needs to be warned to all other application servers that are active in some geographical area, like As1 to AS3, and sends a push notification (<NUM>) to the application servers As1, AS2 and AS3 that are active within the same geographical area.

<FIG> illustrates an example dealing with a severe situation that is sensed by another application server. Like <FIG> also <FIG> illustrates the cellular network, including the CN and the RAN, to which the three application servers AS1 to AS3 are coupled. For example application server AS1 detects a dangerous situation in the road, e.g. a severe accident, a fire, etc. and requests (<NUM>) the network to send push notification (<NUM>) to all other V2X application servers that are active in the involved area. Thus, application server AS1 detects an event that needs to be warned to all other application servers in the area and/or the neighborhood, and the application server AS1 sends a trigger (<NUM>) for a push notification to the network. The network sends a push notification (<NUM>) to the application servers AS2 and AS3 that are active within the same geographical area as AS1. The push notification (<NUM>) may optionally also be den (<NUM>) to the application server AS1.

<FIG> illustrates an example dealing with a severe situation that is sensed by a V2X UE. Like <FIG> also <FIG> illustrates the cellular network, including the CN and the RAN, to which the three application servers AS1 to AS3 are coupled. In addition a UE is depicted that is connected to the application server AS1 via the cellular network. The UE detects an event that needs to be warned to all other application servers AS1 to AS3 in the area and/or neighborhood. The UE communicates with the application server AS1 as is indicated by (<NUM>). In addition, responsive to the detection of the an event the UE sends a trigger (<NUM>') for a push notification to the network. The network sends a push notification (<NUM>) to the application servers AS1 to AS3 that are active within the same geographical area.

In some of the embodiments described above, reference has been made to respective vehicles being either in the connected mode, also referred to as mode <NUM> configuration, or vehicles being in the idle mode, also referred to as mode <NUM> configuration. However, the present invention is not limited to V2V communications or V2X communications, rather it is also applicable to any device-to-device communications, for example non-vehicular mobile users or stationary users that perform a sidelink communication, e.g., over the PC5 interface. Also in such scenarios, scheduling the resources in accordance with the aspects described above is advantageous as it allows for a more efficient scheduling of resources for sidelink communication avoiding resource collisions and the like.

Some embodiments of the present invention have been described above with reference to a communication system in which the transmitter is a base station serving a user equipment, and in which the receiver is the user equipment served by the base station. However, the present invention is not limited to such embodiments and may also be implemented in a communication system in which the transmitter is a user equipment station, and in which the receiver is the base station serving the user equipment. In accordance with other embodiments, the receiver and the transmitter may both be UEs communicating directly with each other, e.g., via a sidelink interface.

In accordance with embodiments, the wireless communication system may include a terrestrial network, or a non-terrestrial network, or networks or segments of networks using as a receiver an airborne vehicle or a spaceborne vehicle, or a combination thereof.

In accordance with embodiments, a receiver may comprise one or more of a mobile or stationary terminal, an loT device, a ground based vehicle, an aerial vehicle, a drone, a building, or any other item or device provided with network connectivity enabling the item/device to communicate using the wireless communication system, like a sensor or actuator. In accordance with embodiments, a transmitter may comprise one or more of a macro cell base station, or a small cell base station, or a spaceborne vehicle, like a satellite or a space, or an airborne vehicle, like a unmanned aircraft system (UAS), e.g., a tethered UAS, a lighter than air UAS (LTA), a heavier than air UAS (HTA) and a high altitude UAS platforms (HAPs), or any transmission/reception point (TRP) enabling an item or a device provided with network connectivity to communicate using the wireless communication system.

Various elements and features of the present invention may be implemented in hardware using analog and/or digital circuits, in software, through the execution of instructions by one or more general purpose or special-purpose processors, or as a combination of hardware and software. For example, embodiments of the present invention may be implemented in the environment of a computer system or another processing system. <FIG> illustrates an example of a computer system <NUM>. The units or modules as well as the steps of the methods performed by these units may execute on one or more computer systems <NUM>. The computer system <NUM> includes one or more processors <NUM>, like a special purpose or a general purpose digital signal processor. The processor <NUM> is connected to a communication infrastructure <NUM>, like a bus or a network. The computer system <NUM> includes a main memory <NUM>, e.g., a random access memory (RAM), and a secondary memory <NUM>, e.g., a hard disk drive and/or a removable storage drive. The secondary memory <NUM> may allow computer programs or other instructions to be loaded into the computer system <NUM>. The computer system <NUM> may further include a communications interface <NUM> to allow software and data to be transferred between computer system <NUM> and external devices. The communication may be in the from electronic, electromagnetic, optical, or other signals capable of being handled by a communications interface. The communication may use a wire or a cable, fiber optics, a phone line, a cellular phone link, an RF link and other communications channels <NUM>.

Claim 1:
A wireless communication system (<NUM>), comprising
a radio access network, RAN, the RAN (<NUM>, <NUM>) including a plurality of RAN entities being respective transmitters and receivers, the plurality of RAN entities comprising one or more base stations, gNBs, and/or one or more user devices, UEs, and
a core network, CN, (<NUM>, <NUM>) coupled to the RAN (<NUM>, <NUM>), wherein an application server (<NUM>) is connectable to the CN (<NUM>, <NUM>), the application server (<NUM>) configured to run an application providing a certain service to a receiver in the RAN (<NUM>, <NUM>) with a certain Quality-of-Service, QoS,
wherein the wireless communication system (<NUM>) is configured to obtain a RAN status of at least a part of the RAN (<NUM>, <NUM>), and to inform the application server (<NUM>) or the receiver configured to run the certain service about the RAN status, the RAN status indicating that the certain QoS cannot be fulfilled by the RAN (<NUM>, <NUM>),
characterized in that
the RAN status indicates QoS requirements achievable in the RAN (<NUM>, <NUM>) so as to allow the application server (<NUM>) or the receiver to adapt to changes in achievable QoS.