WO2018015612A1

WO2018015612A1 - Determining a modulation and coding scheme for a broadcast or multicast transmission

Info

Publication number: WO2018015612A1
Application number: PCT/FI2016/050542
Authority: WO
Inventors: David Navratil; Ling Yu; Vinh Van Phan
Original assignee: Nokia Technologies Oy
Priority date: 2016-07-22
Filing date: 2016-07-22
Publication date: 2018-01-25

Abstract

This specification describes a method comprising, for each of at least two groups of at least one user equipment, UE, within an area served by an access point, determining a modulation and coding scheme, MCS, based on a quality-of-service, QoS, requirement for the group and a determination of a quality of a radio link between the access point and at least one UE in the group, and selecting the most robust of the determined MCSs for use in performance of a broadcast or multicast transmission by the access point for receipt by the UEs in each of the at least two groups.

Description

Determining a Modulation and Coding Scheme for a Broadcast or

Multicast Transmission

Field

This specification relates to the determination of a modulation and coding scheme (MCS) for use in performance of a broadcast or multicast transmission.

Background

One of the aims with future E-UTRA (Advanced LTE) networks is to support Vehicle- to-X (V2X) communication. V2X communication is the passing of information from a vehicle to any entity that may affect the vehicle, and vice versa. This information exchange can be used for a host of safety, mobility and environmental applications to include driver assistance and vehicle safety , speed adaptation and warning, emergency response, safety, traveller information, navigation, traffic operations and demand management, personal navigation, commercial fleet planning and payment

transactions. There may be significant societal benefit and commercial value to delivering safety, mobility and convenience applications that rely on V2X.

Basic entities within a V2X communication system are the vehicle (V) and its connectivity to any other Intelligent Transportation System (ITS) station. Therefore, V2X communication systems include transceivers, in the form of eNodeBs (eNBs) or user equipment (UEs) located on vehicles, mounted on the roadside infrastructure, in aftermarket devices, or within handheld devices. V2X communication may include, but not exclusively, Vehicle to Vehicle (V2V) communication and Vehicle to Infrastructure (V2I) communication.

Recent documents published by the 3 GPP include provisions for the implementation of V2X. However, much of the implementation detail is still marked as "for future study". Summary

In a first aspect, this specification describes a method comprising, for each of at least two groups of at least one user equipment, UE, within an area served by an access point, determining a modulation and coding scheme, MCS, based on a quality-of- service, QoS, requirement for the group and a determination of a quality of a radio link between the access point and at least one UE in the group, and selecting the most robust of the determined MCSs for use in performance of a broadcast or multicast transmission by the access point for receipt by the UEs in each of the at least two groups. Each of the at least two groups may have a different QoS requirement. The method may comprise grouping the UEs within the area served by the access point into the at least two groups based on at least one UE characteristic. The at least one UE characteristic may include at least one of QoS requirement information indicating a QoS requirement for the UE, type information indicating a type of the UE, mode information indicating a mode of operation associated with the UE, location

information indicating a location of the UE, and heading information indicating a heading of the UE. The at least one UE characteristic for a particular UE may be received from the UE or the method may comprise receiving the at least one UE characteristic from a network node other than the UE. The method may comprise receiving location information indicating a location of one of the UEs within the area served by the access point, and grouping the UE into one of the at least two groups based on the location of the UE relative to a location or area of interest. The method may further comprise grouping the UE into one of the at least two groups based on the location of the UE relative to the location or area of interest and a heading of the UE.

Alternatively, the method may comprise receiving type information indicating that a first UE within the area served by the access point is of a first type and that a second UE within the area served by the access point is of a second type, and grouping the first UE and the second UE based on the type information such that the first UE is grouped into a first of the at least two groups and the second UE is grouped into a second of the at least two groups.

The method may comprise determining the QoS requirement for each of the groups based on at least one QoS parameter associated with each group. The QoS

parameter(s) may be pre-stored at the access point, received from at least one of the UEs within the area served by the access point, and/or received from a network node other than the UEs within the area served by the access point. For instance, the QoS parameter for at least one of the at least two groups may be received from at least one UE within the area served by the access point as part of a message indicating that the UE is interested in receiving broadcast or multicast transmissions from the access point.

The method may comprise, in response to receiving a repeat transmission request from one of the UEs within the area served by the access point, determining whether to perform the repeat transmission based on the QoS requirement for the group to which the UE belongs.

In a second aspect, this specification describes apparatus configured to perform any method described with reference to the first aspect.

In a third aspect, this specification describes computer-readable instructions which, when executed by computing apparatus, causes the computing apparatus to perform any method described with reference to the first aspect.

In a fourth aspect, this specification describes apparatus comprising at least one processor, and at least one memory including computer program code which, when executed by the at least one processor, causes the apparatus to determine, for each of at least two groups of at least one user equipment, UE, within an area served by an access point, a modulation and coding scheme, MCS, based on a quality-of-service, QoS, requirement for the group and a determination of a quality of a radio link between the access point and at least one UE in the group, and to select the most robust of the determined MCSs for use in performance of a broadcast or multicast transmission by the access point for receipt by the UEs in each of the at least two groups.

Each of the at least two groups may have a different QoS requirement.

The computer program code, when executed by the at least one processor, may cause the apparatus to group the UEs within the area served by the access point into the at least two groups based on at least one UE characteristic. The at least one UE characteristic may include at least one of: QoS requirement information indicating a QoS requirement for the UE; type information indicating a type of the UE; mode information indicating a mode of operation associated with the UE; location

information indicating a location of the UE; and heading information indicating a heading of the UE. The at least one UE characteristic for a particular UE may be received from the UE. Alternatively, the computer program code, when executed by the at least one processor, may enable receipt of the at least one UE characteristic from a network node other than the UE.

The computer program code, when executed by the at least one processor, may cause the apparatus to receive location information indicating a location of one of the UEs within the area served by the access point, and to group the UE into one of the at least two groups based on the location of the UE relative to a location or area of interest. The computer program code, when executed by the at least one processor, may cause the apparatus to group the UE into one of the at least two groups based on the location of the UE relative to the location or area of interest and a heading of the UE.

The computer program code, when executed by the at least one processor, may cause the apparatus to receive type information indicating that a first UE within the area served by the access point is of a first type and that a second UE within the area served by the access point is of a second type, and to group the first UE and the second UE based on the type information such that the first UE is grouped into a first of the at least two groups and the second UE is grouped into a second of the at least two groups.

The computer program code, when executed by the at least one processor, may cause the apparatus to determine the QoS requirement for each of the groups based on at least one QoS parameter associated with each group.

The at least one QoS parameter may be pre-stored at the access point, received from at least one of the UEs within the area served by the access point, and/or received from a network node other than the UEs within the area served by the access point. For instance, the QoS parameter for at least one of the at least two groups may be received from at least one UE within the area served by the access point as part of a message indicating that the UE is interested in receiving broadcast or multicast transmissions from the access point.

The computer program code, when executed by the at least one processor, may cause the apparatus, in response to receiving a repeat transmission request from one of the UEs within the area served by the access point, to determine whether to perform the repeat transmission based on the QoS requirement for the group to which the UE belongs. In a fifth aspect, this specification describes a computer-readable medium having computer-readable code stored thereon, the computer-readable code, when executed by at least one processor, causing performance of at least, for each of at least two groups of at least one user equipment, UE, within an area served by an access point, determining a modulation and coding scheme, MCS, based on a quality-of-service, QoS,

requirement for the group and a determination of a quality of a radio link between the access point and at least one UE in the group, and selecting the most robust of the determined MCSs for use in performance of a broadcast or multicast transmission by the access point for receipt by the UEs in each of the at least two groups. The computer-readable code stored on the medium of the fifth aspect may further cause performance of any of the operations described with reference to the method of the first aspect.

In a sixth aspect, this specification describes apparatus comprising means for determining, for each of at least two groups of at least one user equipment, UE, within an area served by an access point, a modulation and coding scheme, MCS, based on a quality-of-service, QoS, requirement for the group and a determination of a quality of a radio link between the access point and at least one UE in the group, and means for selecting the most robust of the determined MCSs for use in performance of a broadcast or multicast transmission by the access point for receipt by the UEs in each of the at least two groups. The apparatus of the sixth aspect may further comprise means for causing performance of any of the operations described with reference to the method of the first aspect. Brief Description of the Figures

For better understanding of the present application, reference will now be made, by way of example only, to the accompanying drawings in which:

Figure 1 is an example of a mobile telecommunications radio access network including one or more eNodeBs (eNBs) and one or more user equipments (UEs);

Figures 2 and 3 are respective portions of a mobile telecommunications radio access network such as that of Figure 1 for illustrating various concepts described in this specification;

Figure 4 is a flow chart illustrating various operations which may be performed by an access point operating within a network such as that of Figures 1, 2 and 3;

Figure 5 is a flow chart illustrating various operations which may form part of one or more of the operations described with reference to the flow chart of Figure 4; Figure 6 is a schematic illustration of an example configuration of an access point which may be configured to perform various operations described with reference to Figures l to 5;

Figure 7 is a schematic illustration of an example configuration of a UE which may form part of the network of Figures 1,2 and 3 and may be configured for communication with the access point of Figure 6; and

Figure 8 is an illustration of a computer-readable medium upon which computer readable code may be stored. Detailed Description

In the description and drawings, like reference numerals refer to like elements throughout.

Various methods and apparatuses are described in detail below, by way of example only, in the context of a mobile telecommunications radio access network 1, such as that illustrated in Figure 1. The network 1 comprises one or more base stations or access points (eNodeBs, eNBs) 7. Only a small number of eNBs 7 are shown in FIG. 1, but a radio access network may typically comprise thousands of eNBs 7. Together, the eNBs 7 may provide radio coverage to one or more node over a wide geographical area.

The nodes may comprise a mixture of mobile and non-mobile devices (e.g. a mixture of infrastructural devices and mobile end-user devices). However, for simplicity they will hereafter be referred to as user equipments (UEs) 6. Each eNB 7 operates one or more cells 5, which are denoted in Figure 1, for illustrative purposes only, by the dashed circles or sectors thereof. Although the coverage/ service areas of the cells are shown illustratively in Figure 1 as circles or sectors thereof, in reality, the coverage area of each cell depends on the transmission power and the directionality of the antenna (or antennas) by which the cell is operated. The coverage area of each cell 5 may also depend on obstacles (such as buildings) which are in the vicinity of the eNB 7, carrier frequency and channel propagation characteristics etc.

The configuration of the coverage area of the cells 5 may be selected so as to serve UEs 6 in a particular area while not providing coverage to other areas. For instance, the configuration of a coverage area of a cell may be selected so as to provide coverage for an area in which users are commonly present while not providing coverage for areas in which users are seldom present. For instance, in Figure 1, a first cell 5-1 operated by a first eNB 7-1 is depicted as only providing coverage to an area comprising a sector of a circle. Indeed, in some examples (as illustrated in Figure 1), an eNB 7 may be configured to provide coverage (via a cell) up and/or down a road but not either side of the road.

A single eNB 7 may, in some examples, provide two or more cells 5. For instance, a first cell 5 may be provided in a first direction from the eNB 7 while a second cell 5 may be provided in a different direction. In Figure 1, this is illustrated by a second eNB 7-2 which is shown as operating two different cells 5-2A and 5-2B.

The eNBs 7 may be configured to perform broadcast or multicast transmissions simultaneously to multiple UEs 6 within the service/coverage area of the eNB 7. For instance, the eNBs 7 may be configured to provide Multimedia Broadcast Multicast Services (MBMS). The UEs 6 may be configured to indicate their interest in receiving the broadcast/multicast transmission by sending a message to the eNB 7, such as an MBMS Interest Indication.

When performing a multicast or broadcast transmission, the eNB 7 may select a modulation and coding scheme (MCS) for the transmission. The selection of the MCS may be based on, for instance, radio link conditions within the service area. Different MCSs provide different levels of robustness and spectral efficiency. Typically, an MCS which is robust (and so increases the likelihood of a packet being successfully received) is less spectrally efficient. As such, if radio link conditions are, in general, not good, a more robust MCS may be selected (to the detriment of spectral efficiency). However, if the radio link conditions are good, a less robust (and so more spectrally efficient) MCS may be selected. Because radio link conditions within an area change with time, the MCS that is most appropriate also changes with time. The process, which dynamically selects the MCS, thereby adjusting the performance of the wireless system to changing radio link quality, is commonly known as the link adaptation process.

As will be appreciated from the above, one or more of the UEs 6 may be configured for bi-directional communication with one or more of the eNBs 7. In such examples, the transmission of data from the eNB 7 to the UE 6 may be referred to as "downlink" and the transmission of data from the UE 6 to the eNB 7 may be referred to as "uplink". In some examples, at least some of the UEs 6 within the network ι may be configured to report information about the quality of the radio link between the UE 6 and the eNB 7. This may generally be referred to as channel state information (CSI). In LTE, for instance, the channel state information may be provided to the eNB 7 in the form of channel quality indication (CQI) reports. The reported radio link quality information (e.g. CQI) may be transmitted on a shared channel, e.g. the physical uplink shared channel (PUSCH), or a dedicated channel for the UE 6, e.g. the Physical

Uplink Control Channel (PUCCH). CQIs may, for instance, be reported periodically over the PUCCH and on request over the PUSCH.

In some examples, the eNB 7 may be able to estimate the radio link quality between the eNB 7 and a UE 6 even without receiving radio link quality reports from the UE 6. For instance, the eNB 7 may be configured to estimate the radio link quality based on a location of the UE 6 and stored "Minimization of Drive Tests" (MDT) data.

The UEs 6 may, in some examples, be configured to provide feedback information to the eNBs 7. The feedback information may include indications as to whether or not a broadcast/multicast packet was successfully received by the UE 6. In some examples, an indication that a broadcast/multicast packet was not successfully received may serve as a request for retransmission of the packet. The eNBs 7 may be configured to provide such retransmissions of broadcast/multicast data in response to such requests. . For instance, in some examples, the eNBs 7 and UEs 6 may be configured to utilise hybrid automatic repeat requests (HARQ). In such examples, if a transmission has been successfully received, the UE 6 may transmit a message indicating this (an "ACK" message). In contrast, if a transmitted packet has not been successfully received, the UE 6 may respond by transmitting a "NACK" message. In response to receiving a NACK message, the eNB 7 may respond by re-broadcasting or re-multicasting the data packet. However, as will be understood from the below explanation, the eNB 7 may, in some examples, determine that re-broadcasting or re-multicasting should not be performed even though a retransmission request (e.g. a NACK message) has been received from a particular UE 6.

The feedback information from the UE 6 (e.g. ACK/NACK) may be provided either through a dedicated uplink resource allocated to one UE 6 or through a common uplink resource on which multiple UEs 6 can transmit at the same time. Where the common uplink resource is used, implicit ACKs may be used. Put another way, if the eNB 7 detects that no retransmission request has been received in the common uplink resource allocated for such requests, then the eNB 7 determines that all receiving UEs 6 successfully/correctly received the packet. As can be seen in Figure 6, the UE 6 comprises control apparatus 60 which is configured to control operation of other components forming part of the UE 6, thereby to enable transmission of data, via uplink, to the eNBs 7 as well as receipt of data from the eNBs 7, via downlink. The control apparatus 60 may additionally be configured to cause performance of any other operations described herein with reference to the UEs 6. Example configurations of the control apparatus 60 and the UE 6 as a whole are discussed in more detail below in relation to Figure 6.

Similarly, as illustrated in Figure 7, the eNBs 7 may comprise control apparatus 70 for enabling bi-directional communication with one or more UEs 6, including performance of broadcast and multicast transmissions. The control apparatus 70 may additionally be configured to cause performance of any other operations described herein with reference to the eNBs 7, for instance with reference to Figures 4 and 5. Example configurations of the control apparatus 70 and the eNB 7 as a whole are discussed in more detail below in relation to Figure 7.

The mobile telecommunications radio access network 1 may be, but is not limited to, an Evolved Universal Terrestrial Radio Access (E-UTRA) network, which may sometimes be referred to as LTE Advanced network. The eNBs 7 and UEs 6 in the network 1 may be configured to communicate with one another using an OFDM-based access scheme, such as orthogonal frequency division multiple access (OFDMA) and/or single carrier frequency division multiple access (SC-FDMA). For instance, in some non-limiting examples OFDMA may be used for downlink communications whereas SC-FDMA may be used for uplink communications. In the example of Figure 1, the eNBs 7 are shown as providing coverage to a portion of a transportation system, in this case in the form of a series of roads. In such examples, the UEs 6 may form part of, or be travelling in, vehicles 9, such as cars. As such, the network and entities therein may be said to be configured for V2X communication. UEs 6 which are carried by or integrated in vehicles may be referred to as "vehicle UEs". Messages transmitted by vehicle UEs 6 may include indicators indicating the type or current mode of the vehicle UE. For instance, the vehicle UEs 6 may be configured to transmit a message indicating the UE as a vehicle UE. The UEs may further be configured to provide an indicator indicating that the vehicle is

autonomous/self-driving (or is operating in an autonomous mode) or that the vehicle is configured to provide driver assist (or is in driver assist mode). In this way, the eNBs 7 may be able to distinguish between vehicle UEs and UEs of, for instance pedestrians, and also between different types of vehicle UEs and/or vehicle UEs operating in different modes.

In Figure 1, only a portion of the vehicles 9 and vehicle UEs 6 are indicated using reference numerals. However, it will of course be appreciated that any number of the vehicles travelling in a transportation system may include a vehicle UE 6. As will also be appreciated, Figure 1 (and also Figures 2 and 3) is intended for illustrative purposes only and is not to scale. The network may further include an associated server apparatus 3 (e.g. a V2X server) which may be configured to provide information to the eNBs 7 within the network. The server apparatus 3 (whether a V2X server or not) may be operated by a network provider which deploys/provides/operates at least some of the eNBs 7 in the network 1. In such examples, the server apparatus 3 may be an operation and maintenance (O&M) server for the network provider operating the eNBs 7.

It may not be necessary for an eNB 7 to provide a broadcast/multicast service to all UEs 6 within a particular service/coverage area with the same quality-of-service (QoS). For example, UEs 6 of autonomous driving vehicles may require higher QoS in terms of reliability-latency than the UEs 6 of vehicles with a driver. Similarly, QoS requirements may be different based on UE locations. For instance, vehicle UEs 6 approaching an intersection or any other challenging road section (e.g. due to an accident, abnormal road conditions etc.) may require a higher QoS than vehicle UEs 6 further away. In some instances, the QoS requirement of a particular UE 6 may change dynamically. For example, a need for high-reliability V2X communications (high QoS) may be triggered at an individual vehicle UE 6 in response to determining that local alternatives (e.g. camera or sensor based alternatives) are not effective.

In view of this, the eNBs 7 may be configured to group UEs 6 within their

broadcast/ multicast coverage area into at least two groups (QoS groups) based on the QoS requirements of the UEs 6. For instance, UEs 6 requiring a higher QoS may be grouped into a first QoS group and the UEs 6 requiring a lower QoS may be grouped into second QoS group. Each QoS group of UEs 6 may include at least one UE 6.

The eNB 7 is configured, after grouping the UEs 6, to determine, for each of the at least two groups, a modulation and coding scheme (MCS) based on the QoS requirement for the QoS group and a determination of a radio link quality for at least one of the UEs 6 in the QoS group. The eNB 7 is further configured to select the most robust of the determined MCSs for use in performance of a broadcast or multicast transmission within the coverage area, the broadcast or multicast transmission being for receipt by UEs 6 from each of the at least two QoS groups. As will be appreciated, the selection of the most robust MCS means that QoS requirements of all QoS groups are met.

By operating in this way, the eNBs 7 of the network 1 can support broadcast/multicast services with multiple QoS levels, which can also translate to better spectral efficiency of the network/system 1. Specifically, improvements in the spectral efficiency of the system 1 may be obtained, for example, when all UEs 6 from a first QoS group with higher QoS requirements are experiencing better radio link conditions then all UEs 6 from a second QoS group with lower QoS requirements. The eNB 7 is configured to respond to such situations by selecting a less robust (i.e. more spectral efficient) MCS than it otherwise would have selected if the higher QoS requirements were applied to all UEs 6 within the coverage area.

In examples in which the eNB 7 is configured to perform repeat transmissions, the eNB 7 may be configured to respond to receiving a repeat transmission request from one of the UEs 6 by determining whether to perform the repeat transmission based on the

QoS requirements for the QoS group to which the UE 6 belongs. For instance, if the UE 6 is from a QoS group with low requirements, the eNB 7 may determine that it will not perform the retransmission (if retransmissions are not required in order to meet the QoS requirements of the group). As such, the number of retransmissions that are performed by the eNB 7 may be reduced, thereby saving the various associated computational resources (e.g. processing, power, bandwidth etc.).

The QoS groupings of the UEs 6 may be determined based on one or more of a number of UE characteristics. The characteristics may include, but are not limited to, a QoS requirement of the UE 6, a type of the UE 6, a mode of operation associated with the UE 6, a location of the UE, and a heading (direction of travel) of the UE 6. Information indicating the UE characteristics (e.g. QoS requirement information, type information, location information etc.) may be received by the eNB 7 from the UEs themselves or from another node in the network (e.g. a mobility management entity (MME) in LTE). Examples of characteristics which may be explicitly indicated by the UEs 6 to the eNBs may include the UE type, mode of operation, the UE's location and/or the UE's QoS requirements. However, the eNBs 7 may be configured to determine some

characteristics based on information received from the UEs even if the characteristics aren't explicitly indicated by the received information. For instance, the eNB 7 or some associated server may be configured to determine the heading of the UE 6 based on a series of received location information. Similarly, the eNB 7 may, for instance, have access to a database (which may be operated by an MME and may include subscription information) of UE characteristics of different UEs 6 and, when a UE 6 enters the coverage area of the eNB 7, the eNB may retrieve/receive the UE characteristics of the UE (e.g. type, QoS requirements etc.) based on an identifier of the UE 6.

QoS requirement information may be provided by the UE 6 in the form of a QoS grouping indicator, which indicates a QoS group into which the UE should be placed. Alternatively, the UE 6 may explicitly indicate the QoS requirement parameters to the eNB, for instance as part of a message indicating an interest to receive

broadcast/multicast services. As mentioned previously, the UEs 6 may be configured to change their QoS requirements based on conditions being experienced.

The eNB 7 may be pre-configured with (or may have previously received from another network node) the QoS parameters for each potential QoS group. As such, once the eNB has grouped the UEs into the at least two QoS groups based on one or more UE characteristic, the eNB 7 may retrieve the pre-stored QoS parameters for the at least two QoS groups. These QoS parameters may then be used in the determination of the MCS for each group. The QoS parameters may include, for instance, any combination of packet delay budget, packet error loss rate, priority level, and/ or pre-emption.

Figures 2 and 3 show different portions of an access network 1 such as that of Figure 1 and are for illustrating examples of how the above-described beneficial operations of the eNB 7 may be applied. In both of Figures 2 and 3, the network is providing coverage to a portion of a transportation system, in this case in the form of a series of roads. As such, the eNB 7 is, in both cases, configured for V2X communication with vehicle UEs 6.

In Figure 2, vehicle UEs 6 are travelling along a highway, on which there has been an accident. In such a situation, it may be more beneficial for vehicle UEs 6 closer to the location of the accident to receive a higher QoS, whereas it may not be so beneficial for vehicles further away to receive the higher QoS.

The eNB 7 may therefore be configured to group the UEs 6 into QoS groups based on their location. For instance, all UEs 6 within a threshold distance of the accident (marked by the dashed line denoted T in Figure 2) may be grouped into a first QoS group having a higher QoS requirement. All UEs 6 outside the threshold distance may by grouped into a second QoS group having a lower QoS requirement. In Figure 2, all UEs in the first group are labelled 6-1 and all UEs in the second group are labelled 6-2. The eNB 7 may be aware of the locations of the UEs based on messages including location information which may be regularly transmitted to the eNB 7 by the UEs 6.

Having grouped the UEs 6 into at least two QoS groups, the eNB 7 may then perform link adaptation independently for the UEs 6 in each QoS group, thereby to determine the most appropriate MCS for each group. Subsequently, the eNB 7 selects the MCS that is the most robust and uses this for its broadcast/multicast transmissions. In the example of Figure 2, vehicle UEs 6-1 in the first QoS group are closer to the eNB 7 and so may all have better channel conditions (at least because of a lower path loss) than do the UEs 6-2 which are in the second QoS group, which are further from the eNB 7. As such, an improvement in spectral efficiency may be obtained.

In the example of Figure 3, the eNB 7 is providing coverage around an intersection of a road network. In such a situation, it may be more beneficial for vehicles UEs 6 approaching the intersection to receive a higher QoS, whereas it may not be so beneficial for vehicle UEs which are further away from the intersection and/or are leaving the intersection to receive the higher QoS.

The eNB 7 may therefore be configured to group the UEs 6 into QoS groups based on their location and their heading. For instance, all UEs 6-1 which are within a predetermined area A (which may be centred on the intersection) and which are heading towards the intersection may be grouped into the first QoS group having relatively high QoS requirements. All UEs 6-2 which are heading away from the intersection may be grouped into the second QoS group having relatively low QoS requirements. A third QoS group may also be formed which includes all UEs 6-3 which are outside the predetermined area A but which are heading towards the intersection. The third QoS group may be determined to have a QoS requirement which is between those of the first and second QoS groups.

Grouping UEs into QoS groups based on location (as in Figures 2 and 3) may be performed by comparing a location of the UE 6 with a pre-determined geographic area, as is the case with the example of Figure 3. Alternatively, a distance between the location of the UE 6 and a point of interest may be determined and the distance may be compared with a threshold (as is the case in the example of Figure 2). The point of interest, the threshold distance and/or information defining the geographic area (which may take any appropriate shape) may be received by the eNB 7 from, for instance, the V2X server apparatus 3.

As will of course be appreciated, the situations described with reference to Figures 2 and 3 are examples only and the UEs 6 may be grouped into QoS groups based on any combination of UE characteristics. For instance, the vehicle UE type (or mode of operation, e.g. autonomous, driver assisting etc.) may additionally be taken into account. As such, let us assume that in the example of Figure 3 some of the vehicle UEs 6 are associated with autonomous vehicles (or vehicles operating in autonomous mode) and others are associated with driver-assisting vehicles (or vehicles operating in driver- assist mode). In such an example, it may be considered more beneficial to provide a high QoS to UEs of autonomous vehicles than to UEs of driver assisting vehicles. Thus, the third QoS group may, for example, be divided into two QoS groups, one in which the vehicle UEs are autonomous and one in which they are driver assisting. The group of autonomous vehicle UEs may then be designated a higher QoS requirement than are the group of driver assisting vehicle UEs.

Figure 4 is a flow chart illustrating various operations which may be performed by an eNB 7 when performing broadcast/multicast transmissions.

In operation S4.1, the eNB 7 may receive UE characteristics, based on which it can group the UEs 6 into QoS groups. As discussed above, the one or more UE characteristics based on which the QoS groups are formed may be received from the UEs 6, may be received from another entity (e.g. an MME) and/or may be retrieved from memory (either local to the eNB or remote) based on identifiers of the UEs. At least some of the one or more UE characteristics may be received as part of an indication from the UE 6 that it is interested in receiving broadcasts/multicasts from the eNB 7 (e.g. an MBMS Interest Indication).

As will be appreciated, at least some of the UE characteristics may be changing regularly (e.g. location, heading, mode of operation, QoS requirements). As such, in some examples, the receipt of UE characteristics (operation S4.1) may be an ongoing process, such that the UE characteristic are always up-to-date. In other examples in which the UE characteristic(s) upon which grouping is performed does not change (e.g. UE type), the UE characteristic(s) may be received from each UE 6 only once, when it enters the coverage area of the eNB 7.

In operation S4.2, the eNB 7 may receive reported radio link quality information (e.g. CQIs) and/or feedback information (e.g. receipt acknowledgements/retransmission requests, such as ACKS/NACK) from the UEs 6 within its coverage area. The reported radio link quality information and/or the feedback information may be stored for later use.

Subsequently, in operation S4.3, the eNB 7 determines that there is data to be broadcast/multicast to the UEs 6 in its coverage area (or at least to those UEs from which it has received an indication of interest in receiving multicast/broadcast transmissions).

In response to determining that there is data to be broadcast/multicast, the eNB 7 may (in operation S4.4) respond by grouping the UEs 6 in its coverage area into at least two QoS groups. As discussed above, the grouping may be performed based on any suitable combination of UE characteristics which may include, but are not limited to a QoS requirement of the UE 6, a type of the UE 6, a mode of operation associated with the UE 6, a location of the UE, a heading (direction of travel) of the UE 6.

In operation S4.5, the eNB may use the QoS groupings determined in operation S4.4 to determine an appropriate MCS for each QoS group. The MCS may be determined based on a minimum QoS requirement for each QoS group and radio link quality information for each UE 6 in the group. As discussed previously, the radio link quality for the UEs 6 in at least some of the QoS groups may be determined based on the information received in operation S4.2. The minimum QoS requirement for each group may be defined by QoS parameters which define a minimum QoS for the group. The QoS parameters for the QoS groups may be pre-configured into the eNB 7, may be received from another entity (e.g. V2X server 3) and/or may be received from the UEs 6.

The determination of the appropriate MCS for each QoS group may comprise determining the most suitable MCS for the UE 6 having the worst radio link quality. As such, the eNB 7 may determine which UE 6 has the worst radio link quality (e.g. based on CQI reports) and may then use a value associated with the worst radio link quality and the minimum QoS requirement for the group to determine the MCS for the group. As will be discussed in more detail with respect to Figure 4, determination of the MCS may, in some examples, utilise outer loop link adaptation (OLLA) and/or inner loop link adaptation (ILLA) or neither OLLA nor ILLA. The MCS for different QoS groups may be determined differently and may depend on the information that is available in relation to the UEs 6 in that group.

Inner loop link adaptation is based on the use of radio link quality thresholds (e.g. Signal to Interference plus Noise Ratio (SINR) thresholds). Specifically, a suitable radio link quality threshold may set for each supported MCS. When performing ILLA, the eNB 7 may be configured to select the highest MCS which meets the minimum QoS requirement for the particular QoS group depending on the radio link qualities of the radio links with the UEs in the QoS group. As mentioned previously, CQIs from each of the UEs in a group may indicate the radio link quality with that UE.

Outer loop link adaptation (OLLA) is configured so as to keep a packet error rate (PER) at a given level by adjusting the adaptation of the radio link quality thresholds dynamically, although the difference between the thresholds is kept the same. This may be achieved by assigning a UE 6 with a specific offset, which is used to shift the estimated radio link quality (e.g. SINR) thresholds. Outer loop link adaptation is discussed in more detail with respect to Figure 5. Subsequent to determining the MCS for each QoS group, the eNB 7 selects (in operation S4.6) the most robust of the determined MCSs.

In operation S4.7, the selected MCS is then used by the eNB 7 for performance of the broadcast/multicast transmission to the UEs 6 in each of the groups. After this, although not illustrated in Figure 4, the method may end (or return to operation S4.1). Alternatively, if the eNB 7 is configured to provide retransmissions at the request of the UEs 6 (e.g. is configured for HARQ), the eNB 7 may proceed to operation S4.8. In operation S4.8, the eNB 7 determines if any retransmission requests (e.g. HARQ

NACKS) have been received. If no retransmission requests have been received, the eNB 7 may determine that the transmission was received successfully by all recipients and the method may end (or return to operation S4.1). If one or more retransmission requests have been received, the eNB 7 may proceed to operation S4.9.

When sending retransmission requests (e.g. NACKS), UEs 6 having an active connection with the network (e.g. UEs 6 in a CONNECTED state) may be configured to utilise the existing synchronization timing advance (see, for instance, 3GPP TS 36.300 clause 10.1.2.7) and the same channel each time they send a retransmission request. The channel may be dedicated for a particular UE or may be shared for UEs of a QoS group. As such, the eNB 7 may be configured to recognise a signal received at a particular time (which is dependent on the time multiplexing and scheduling of a particular channel) on a particular channel as being a retransmission request from a particular UE or QoS group of UEs.

UEs 6 which do not have an active connection with the network and so are not synchronised with the eNB 7 (such as UEs 6 in an IDLE state) may, for instance, be configured to send retransmission requests (e.g. NACKS) via a signal which includes a specific pattern or signature (for instance, similar to a random access channel, RACH, preamble). The specific pattern or signature may identify the signal as a retransmission request. Moreover, the UEs in a particular QoS group may utilize a predefined common timing offset (relative to the transmission of the data by the eNB 7 (it should be noted that this is different to a timing advance)) and a predefined common channel when sending retransmission requests. In this way, retransmission requests from a particular QoS group may be identified by the eNB 7 based only on the received power on the channel at a time that is dependent on the predefined offset. In operation S4.9, the eNB 7 determines whether the retransmission should be performed. This may be determined based on the QoS requirements of the group(s) to which the UE 6, from which the retransmission request is received, belongs. For instance, if retransmission requests are only received from UEs belonging to QoS groups having low QoS requirements, the eNB 7 may determine that no retransmission should be performed (if this allows the QoS requirements still to be satisfied). If, on the other hand, a retransmission request is received from UEs 6 belonging to QoS groups having a higher QoS requirement, which may only be met if the retransmission is performed, the eNB 7 may determine that the retransmission should be performed.

In response to determining that the retransmission should not be performed, the method may end (or return to operation S4.1). In response to determining that the retransmission should be performed, the eNB 7 proceeds to operation S4.10 in which the retransmission is performed. As will be appreciated, the broadcast/multicast retransmission may be received by all UEs in the coverage area. In some other examples, however, in response to determining that retransmission should be performed (e.g. based on the QoS group to which a requesting UE 6 belongs), the eNB 7 may be configured to utilize unicasting (point-to-point transmission) for

retransmission of the data to (or, put another way, for receipt by) only the UE 6 which requests the retransmission. This may occur, for instance, when the retransmission request is received by the eNB 7 from a single UE 6 which is in a CONNECTED state.

After performing the retransmission, the eNB 7 may return to operation S4.8 to determine if a retransmission request from the UE 6 which requested the first transmission has been received. If no request is received, the method may end (or may return to operation S4.1). If a request is received, the eNB 7 may proceed to operations S4.9 and S4.10. Operations S4.8, S4.9 and S4.10 may be repeated until a negative determination is received in operation S4.8 and QoS requirements are met (e.g.

retransmission occurs within a packet delay budget), after which the method may end (or may return to operation S4.1).

Figure 5 is a schematic illustration of examples of various operations which may be performed by the eNB 7 when determining the MCSs for each QoS group of UEs 6 (e.g. when performing operation S4.5 of Figure 4). The flow of operations depicted in Figure 5 may be performed for each of the QoS groups. In operation S4.5.1, the eNB 7 may determine if reported radio link quality information (e.g. CQI reports) is available for the UEs 6 in the particular QoS group. In response to a positive determination, the eNB 7 may proceed to operation S4.5.2 and, in response to a negative determination, the eNB 7 may proceed to operation S4.5.3.

If radio link quality reports are available, in operation S4.5.2, the eNB 7 may determine if outer loop link adaptation (OLLA) is to be applied. This determination may be based on, for instance, the QoS requirements of the QoS group, reporting configuration of UEs and/or availability of information at the network about the number of UEs in the QoS group interested in a broadcast/multicast service. For instance, OLLA may not be applied for a QoS group having lower QoS requirement and may be applied for QoS groups having higher QoS requirements. In other examples, the eNBs 7/network may configure UEs 6 of one or more QoS groups with lower QoS requirements so as not provide feedback information (e.g. positive/ negative reporting of successful broadcast/multicast reception). In this way utilisation of uplink radio resources may be reduced. Similarly, the UEs 6 may be configured by the eNBs 7 so as to not respond to counting request messages which are multicast/broadcast by the eNB 7 and which ordinarily would result in UEs responding by expressing interest in a particular service (thereby enabling the eNB to count the number of UEs that are interested in a particular service). Specifically, if the eNB 7 decides that it does not want to use OLLA for a QoS group then it may respond by configuring the UEs of the QoS group so as not to respond to the multicast/broadcast counting request messages. If reported radio link quality information is not available, in operation S4.5.3 the eNB 7 may determine the MCS for the group based on estimated radio link quality

information (such as MDT data in conjunction with the locations of the UEs in the group) and the QoS requirements of the group. Specifically, this determination may be performed based on the QoS requirements for the group and the lowest estimated radio link quality of the UEs in the group. The determination may be made for instance using ILLA.

If radio link quality reports are available but it is determined that OLLA is not to be applied for the QoS group, in operation S4.5.4 the eNB 7 may determine an MCS for the group based on the radio link quality reports (e.g. CQI) and the QoS requirements of the group. Specifically, this determination may be performed based on the QoS requirements for the group and the reported radio link quality of the UE which has the lowest radio link quality in the group. The determination may be made for instance using ILLA. If reported radio link quality information is available and it is determined (in operation S4.5.2) that OLLA is to be applied for the group, the eNB 7 proceeds to operation S4-5-5. In operation S4.5.5, the eNB 7 may determine whether previous feedback information (e.g. information regarding previous ACKS/NACKS) is available for the UEs 6 in the group.

If it is determined that feedback information is not available, the eNB proceeds to operation S4.5.6 in which it calculates the "offset" for use in OLLA based on the number of UEs in the group and in the absence of feedback information. If it is determined that feedback information is available, the eNB 7 proceeds to operation S4.5.7 in which it calculates the "offset" for use in OLLA based on the number of UEs in the group and the feedback information.

After determining the offset in either of operations S4.5.6 and S4.5.7, the eNB 7 proceeds to operation S4.5.8 in which the MCS is determined for the group based on the calculated offset, the reported radio link quality information (e.g. CQI information) and the QoS requirements for the group. Specifically, the eNB 7 may use the lowest reported radio link quality of all the UEs in the group when determining the MCS. The calculation of the offset in operations S4.5.6 and S4.5.7 and the determination of the MCS in operation S4.5.8 may be performed, for instance, as described in "System- Level Analysis of Outer Loop Link Adaptation on MobileWiMAX Systems, The 7th International Telecommunications Symposium (ITS 2010) by Andre M. Cavalcante, et al.

After determining the MCS for the QoS group (in any of operations S4.5.3, S4.5.4 and S4.5.8) the eNB 7 may proceed to operation S4.6 of Figure 4. Alternatively, in some examples, such as illustrated in Figure 5, the eNB 7 may proceed to operation S4.5.9. In operation S4.5.9, the eNB 7 may determine if the selected MCS (in any of operations S4-5-3, S4.5.4 and S4.5.8) meets the required QoS of QoS group (e.g. taking into the account possible retransmissions within a packet delay budget). If it is determined that the selected MCS does not meet the required QoS (e.g. the most robust MCS available is not expected to provide the target block error rate), then the eNB 7 may decide that block repetition is to be performed (after the transmission of operation S4.7). Block repetition may include the retransmission of data after initial transmission but prior to reception of any feedback (e.g. NACK(S)) from the UEs 6 in the group. This may serve to increase the reception probability (i.e. lower the block error rate) in a shorter time (e.g. due to packet delay budget). When repeating the transmission of the data first transmitted in operation S4.7, the eNB 7 may, for instance, use a different redundancy version of the encoded block. The retransmission may or may not be performed using HARQ.

If, instead, it is determined in operation S4.5.9 that the selected MCS does meet the required QoS for the QoS group, the eNB 7 may proceed to operation S4.6 and block repetition is not subsequently performed. As will be appreciated, the flow charts of Figures 4 and 5 are examples only. As such, various operations may be omitted, re-ordered or combined. For instance, in some examples, the order of operations S4.3 and S4.4 of Figure 4 may be switched. As such, the eNB 7 may be configured to continuously/regularly group the UEs into QoS groups based on the current UE characteristics (operation S4.4). Put another way, the eNB 7 may be configured to regularly/continuously update the QoS groupings. In response to determining that there is data for transmission (in operation S4.3), the eNB 7 may use the current QoS groupings for performance of operation S4.5.

Figure 6 is a schematic illustration of an example configuration of one or more of the UEs 6 depicted in Figures 1, 2 and 3, which may be used for communicating with the eNBs 7 and other UEs via a wireless interface. The UE 6 may be any device capable of at least sending and receiving radio signals to and from the eNBs 7 and of performing the various operations described above with respect to UEs 6. As mentioned previously, in some examples, the UEs 6 may be integrated or otherwise carried in a vehicle (may be a vehicle UE). The UE 6 may communicate via an appropriate radio interface arrangement 605 of the UE 6. The interface arrangement 605 may be provided for example by means of a radio part 605-2 (e.g. a transceiver) and an associated antenna arrangement 605-1. The antenna arrangement 605-1 may be arranged internally or externally to the UE 6.

As discussed above, the UE 6 comprises control apparatus 60 which is operable to control the other components of the UE 6 in addition to performing any suitable combinations of the operations described in connection with UE 6 with reference to Figures 1 to 5. The control apparatus 60 may comprise processing apparatus 601 and memory 602. Computer-readable code 602-2A may be stored on the memory, which when executed by the processing apparatus 601, causes the control apparatus 60 to perform any of the operations described herein in relation to the UE 6. Example configurations of the memory 602 and processing apparatus 601 will be discussed in more detail below.

The UE 6 may further comprise a positioning module 606 for determining its geographic location. This module 606 may determine the location of the UE 6 in any suitable way and may be for instance a global Navigation satellite system (GNSS) module.

The UE 6 may be, for example, a device that does not need human interaction, such as an entity that is involved in Machine Type Communications (MTC). Alternatively, the UE 6 may be a device designed for tasks involving human interaction such as making and receiving phone calls between users, and streaming multimedia or providing other digital content to a user. Non-limiting examples include a smart phone, a laptop computer, a notebook computer, a tablet computer, an e-reader device, and an onboard computer provided with a wireless interface facility.

In implementations in which the UE 6 is a device designed for human interaction, the user may control the operation of the UE 6 by means of a suitable user input interface UII 604 such as key pad, voice commands, touch sensitive screen or pad, combinations thereof or the like. A display 603, a speaker and a microphone may also be provided. Furthermore, the UE 6 may comprise appropriate connectors (either wired or wireless) to other devices and/or for connecting external accessories, for example hands-free equipment, thereto. Figure 7 is a schematic illustration of an example configuration of one or more of the eNBs 7 depicted in Figures 1,2 and 3, which may be used for communicating with the UEs 6 (and other network entities, such as the server apparatus 3, when appropriate) via a wireless interface. The eNB 7, which may be referred to a base station or access point (AP), comprises a radio frequency antenna array 701 configured to receive and transmit radio frequency signals. Although the eNB 7 in Figure 7 is shown as having an array 701 of four antennas, this is illustrative only. The number of antennas may vary, for instance, from one to many hundreds. The eNB 7 further comprises a radio frequency interface 703 configured to interface the radio frequency signals received and transmitted by the antenna 701 and a control apparatus 70. The radio frequency interface 703 may also be known as a transceiver. The apparatus 70 may also comprise an interface 709 via which, for example, it can communicate (e.g. via X2 messages) with other network elements such as the other eNBs 7 and the server apparatus 3.

The eNB control apparatus 70 may be configured to process signals from the radio frequency interface 703, control the radio frequency interface 703 to generate suitable RF signals to communicate information to the UEs 6 via the wireless communications link, and also to exchange information with other eNBs 7 and the server apparatus 3 via the interface 709. .

The control apparatus 70 may comprise processing apparatus 702 and memory 704. Computer-readable code 704-2A may be stored on the memory 704, which when executed by the processing apparatus 702, causes the control apparatus 70 to perform any of the operations assigned to the eNBs 7 and described with reference to any of Figures 1 to 5.

As should of course be appreciated, the apparatuses 6, 7 shown in each of Figures 6 and 7 and described above may comprise further elements which are not directly involved with processes and operations in respect which this application is focussed.

Some further details of components and features of the above-described

apparatus/entities/apparatuses 3, 6, 7, 60, 70 and alternatives for them will now be described. The control apparatuses described above 60, 70 may comprise processing apparatus 601, 702 communicatively coupled with memory 602, 704. The memory 602, 704 has computer readable instructions 602-2A, 704-2A stored thereon, which when executed by the processing apparatus 601, 702 causes the control apparatus 60, 70 to cause performance of various ones of the operations described with reference to Figures 1 to 7. The control apparatus 60, 70 may in some instance be referred to, in general terms, as "apparatus".

The processing apparatus 601, 702 may be of any suitable composition and may include one or more processors 601A, 702A of any suitable type or suitable combination of types. Indeed, the term "processing apparatus" should be understood to encompass computers having differing architectures such as single/multi-processor architectures and sequencers/parallel architectures. For example, the processing apparatus 601, 702 may be a programmable processor that interprets computer program instructions 602- 2A, 704-2A and processes data. The processing apparatus 601, 702 may include plural programmable processors. Alternatively, the processing apparatus 601, 702 may be, for example, programmable hardware with embedded firmware. The processing apparatus 601, 702 may alternatively or additionally include one or more specialised circuit such as field programmable gate arrays FPGA, Application Specific Integrated Circuits (ASICs), signal processing devices etc. In some instances, processing apparatus 601, 702 may be referred to as computing apparatus or processing means.

The processing apparatus 601, 702 is coupled to the memory 602, 704 and is operable to read/write data to/from the memory 602, 704. The memory 602, 704 may comprise a single memory unit or a plurality of memory units, upon which the computer readable instructions (or code) 602-2A, 704-2A is stored. For example, the memory 602, 704 may comprise both volatile memory 602-1, 704-1 and non-volatile memory 602-2, 704- 2. In such examples, the computer readable instructions/program code 602-2A, 704- 2A may be stored in the non-volatile memory 602-2, 704-2 and may be executed by the processing apparatus 601, 702 using the volatile memory 602-1, 704-1 for temporary storage of data or data and instructions. Examples of volatile memory include RAM, DRAM, and SDRAM etc. Examples of non-volatile memory include ROM, PROM, EEPROM, flash memory, optical storage, magnetic storage, etc. The memory 602, 704 may be referred to as one or more non-transitory computer readable memory medium or one or more storage devices. Further, the term 'memory', in addition to covering memory comprising both one or more non-volatile memory and one or more volatile memory, may also cover one or more volatile memories only, one or more non-volatile memories only. In the context of this document, a "memory" or "computer-readable medium" may be any media or means that can contain, store, communicate, propagate or transport the instructions for use by or in connection with an instruction execution system, apparatus, or device, such as a computer.

The computer readable instructions/program code 602-2A, 704-2A may be preprogrammed into the control apparatus 60, 70. Alternatively, the computer readable instructions 602-2A, 704-2A may arrive at the control apparatus via an electromagnetic carrier signal or may be copied from a physical entity 80 such as a computer program product, a memory device or a record medium such as a CD-ROM or DVD an example of which is illustrated in Figure 8. The computer readable instructions 602-2A, 704-2A may provide the logic and routines that enables the entities devices/apparatuses 6, 7 to perform the functionality described above. The combination of computer-readable instructions stored on memory (of any of the types described above) may be referred to as a computer program product. In general, references to computer program, instructions, code etc. should be understood to express software for a programmable processor firmware such as the programmable content of a hardware device as instructions for a processor or configured or configuration settings for a fixed function device, gate array, programmable logic device, etc.

If desired, the different functions discussed herein may be performed in a different order and/or concurrently with each other. Furthermore, if desired, one or more of the above-described functions may be optional or may be combined.

Although the method and apparatus have been described in connection with an E- UTRA network, it will be appreciated that they are not limited to such networks and are applicable to radio networks of various different types.

Although various aspects of the methods, apparatuses described herein are set out in the independent claims, other aspects may comprise other combinations of features from the described embodiments and/or the dependent claims with the features of the independent claims, and not solely the combinations explicitly set out in the claims. It is also noted herein that while the above describes various examples, these descriptions should not be viewed in a limiting sense. Rather, there are several variations and modifications which may be made without departing from the scope of the present invention as defined in the appended claims.

Claims

1. A method comprising:

for each of at least two groups of at least one user equipment, UE, within an area served by an access point, determining a modulation and coding scheme, MCS, based on a quality-of-service, QoS, requirement for the group and a determination of a quality of a radio link between the access point and at least one UE in the group; and selecting the most robust of the determined MCSs for use in performance of a broadcast or multicast transmission by the access point for receipt by the UEs in each of the at least two groups.

2. The method of claim 1, wherein each of the at least two groups has a different QoS requirement.

3. The method of claim 1 or claim 2, comprising:

grouping the UEs within the area served by the access point into the at least two groups based on at least one UE characteristic.

4. The method of claim 3, wherein the at least one UE characteristic includes at least one of:

QoS requirement information indicating a QoS requirement for the UE;

type information indicating a type of the UE;

mode information indicating a mode of operation associated with the UE; location information indicating a location of the UE; and

heading information indicating a heading of the UE.

5. The method of claim 3 or claim 4, wherein the at least one UE characteristic for a particular UE is received from the UE.

6 The method of claim 3 or claim 4, comprising receiving the at least one UE characteristic from a network node other than the UE.

7. The method of any preceding claim, comprising:

receiving location information indicating a location of one of the UEs within the area served by the access point; and grouping the UE into one of the at least two groups based on the location of the UE relative to a location or area of interest.

8. The method of claim 7, comprising grouping the UE into one of the at least two groups based on the location of the UE relative to the location or area of interest and a heading of the UE.

9. The method of any of claims 1 to 6, comprising:

receiving type information indicating that a first UE within the area served by the access point is of a first type and that a second UE within the area served by the access point is of a second type; and

grouping the first UE and the second UE based on the type information such that the first UE is grouped into a first of the at least two groups and the second UE is grouped into a second of the at least two groups.

10. The method of any preceding claim, comprising determining the QoS requirement for each of the groups based on at least one QoS parameter associated with each group.

11. The method of claim 10, wherein the QoS parameter is:

pre-stored at the access point;

received from at least one of the UEs within the area served by the access point; and/or

received from a network node other than the UEs within the area served by the access point.

12. The method of claim 10, wherein the QoS parameter for at least one of the at least two groups is received from at least one UE within the area served by the access point as part of a message indicating that the UE is interested in receiving broadcast or multicast transmissions from the access point.

13. The method of any preceding claim, comprising:

in response to receiving a repeat transmission request from one of the UEs within the area served by the access point, determining whether to perform the repeat transmission based on the QoS requirement for the group to which the UE belongs.

14. Apparatus configured to perform the method of any of claims 1 to 13.

15. Computer-readable instructions which, when executed by computing apparatus, causes the computing apparatus to perform the method of any of claim 1 to 13.

16. Apparatus comprising:

at least one processor; and

at least one memory including computer program code which, when executed by the at least one processor, causes the apparatus:

to determine, for each of at least two groups of at least one user equipment, UE, within an area served by an access point, a modulation and coding scheme, MCS, based on a quality-of-service, QoS, requirement for the group and a determination of a quality of a radio link between the access point and at least one UE in the group; and

to select the most robust of the determined MCSs for use in performance of a broadcast or multicast transmission by the access point for receipt by the

UEs in each of the at least two groups.

17. The apparatus of claim 16, wherein each of the at least two groups has a different QoS requirement.

18. The apparatus of claim 16 or claim 17, wherein the computer program code, when executed by the at least one processor, causes the apparatus to group the UEs within the area served by the access point into the at least two groups based on at least one UE characteristic.

19. The apparatus of claim 18, wherein the at least one UE characteristic includes at least one of:

QoS requirement information indicating a QoS requirement for the UE;

type information indicating a type of the UE;

mode information indicating a mode of operation associated with the UE;

location information indicating a location of the UE; and

heading information indicating a heading of the UE.

20. The apparatus of claim 18 or claim 19, wherein the at least one UE characteristic for a particular UE is received from the UE.

21 The apparatus of claim 18 or claim 19, wherein the computer program code, when executed by the at least one processor, causes the apparatus to enable receipt of the at least one UE characteristic from a network node other than the UE.

22. The apparatus of any of claims 16 to 21, wherein the computer program code, when executed by the at least one processor, causes the apparatus to:

receive location information indicating a location of one of the UEs within the area served by the access point; and

group the UE into one of the at least two groups based on the location of the UE relative to a location or area of interest.

23. The apparatus of claim 22, wherein the computer program code, when executed by the at least one processor, causes the apparatus to:

group the UE into one of the at least two groups based on the location of the UE relative to the location or area of interest and a heading of the UE.

24. The apparatus of any of claims 16 to 21, wherein the computer program code, when executed by the at least one processor, causes the apparatus to:

receive type information indicating that a first UE within the area served by the access point is of a first type and that a second UE within the area served by the access point is of a second type; and

group the first UE and the second UE based on the type information such that the first UE is grouped into a first of the at least two groups and the second UE is grouped into a second of the at least two groups.

25. The apparatus of any of claims 16 to 24, wherein the computer program code, when executed by the at least one processor, causes the apparatus to determine the QoS requirement for each of the groups based on at least one QoS parameter associated with each group.

26. The apparatus of claim 25, wherein the QoS parameter is:

pre-stored at the access point;

received from at least one of the UEs within the area served by the access point; and/or received from a network node other than the UEs within the area served by the access point.

27. The apparatus of claim 25, wherein the QoS parameter for at least one of the at least two groups is received from at least one UE within the area served by the access point as part of a message indicating that the UE is interested in receiving broadcast or multicast transmissions from the access point.

28. The apparatus of any of claims 16 to 27, wherein the computer program code, when executed by the at least one processor, causes the apparatus, in response to receiving a repeat transmission request from one of the UEs within the area served by the access point, to determine whether to perform the repeat transmission based on the QoS requirement for the group to which the UE belongs.

29. A computer-readable medium having computer-readable code stored thereon, the computer-readable code, when executed by at least one processor, causing performance of at least:

30. Apparatus comprising:

means for determining, for each of at least two groups of at least one user equipment, UE, within an area served by an access point, a modulation and coding scheme, MCS, based on a quality-of-service, QoS, requirement for the group and a determination of a quality of a radio link between the access point and at least one UE in the group; and

means for selecting the most robust of the determined MCSs for use in performance of a broadcast or multicast transmission by the access point for receipt by the UEs in each of the at least two groups.