Traitement en cours

Veuillez attendre...

Paramétrages

Paramétrages

Aller à Demande

1. WO2020156677 - PROCÉDÉS ET APPAREIL DE DÉLESTAGE DE TRAFIC DE DONNÉES DANS UN RÉSEAU SANS FIL

Note: Texte fondé sur des processus automatiques de reconnaissance optique de caractères. Seule la version PDF a une valeur juridique

[ EN ]

Methods and apparatus for offloading data traffic in a wireless network

Field

This disclosure relates to communications, and more particularly to methods and apparatus for data offloading in a wireless communication system.

Background

A communication system can be seen as a facility that enables communica-tion between two or more devices such as terminal devices (e.g. user terminals, machine-like terminals, user equipment (UE) or other types of end devices), base stations and/or other nodes by providing communication channels for carrying in formation between the communicating devices. The communication may comprise, for example, communication of data for carrying data for voice, electronic mail (email), text message, multimedia and/or content data communications and so on.

A communication system and associated devices typically operate in ac cordance with a given standard or specification which sets out what the various entities associated with the system are permitted to do and how that should be achieved. Since introduction of fourth generation (4G) services increasing interest has been paid to the next, or fifth generation (5G) standard. 5G may also be re ferred to as a New Radio (NR) network. Standardization of 5G or NR networks has been finalized in 3GPP release 15.

Direct communication among terminal devices via sidelink or device-to-de-vice (D2D) communication is expected to be in focus of Release 17 of the 5G stand-ard. Sidelink communication enables a paradigm shift away from star-like network topologies towards more meshed communication topologies. The current Release 15 standard does not specify how traffic will be handed off to sidelink, and it does not enable using infrastructure to optimize service quality. As an example, mobile data offloading can be achieved by using such or other complementary network technologies for delivering data originally targeted for cellular networks. Offloading may reduce the amount of data being carried on cellular bands, freeing bandwidth for other users and/or allowing users to connect via wired services with better con nectivity.

Summary

There is provided according to a first aspect an apparatus comprising means for performing:

receiving from at least one network access device measurement reports about communication links at two or more terminal devices;

deriving from the received measurement reports at least one recommenda tion for a sidelink coordination at the two or more terminal devices, wherein the sidelink coordination determines at least one of a direct mode where data traffic is transmitted via a direct communication link between terminal devices and a split mode where data traffic is split between the direct communication link and a relayed communication link via the at least one network access device; and

signalling the at least one recommendation to the at least one network ac-cess device.

According to a second aspect, there is provided an apparatus comprising means for performing:

receiving at a network access device at least one recommendation for a sidelink coordination at two or more terminal devices, wherein the sidelink coordi-nation determines at least one of a direct mode where data traffic is transmitted via a direct communication link between terminal devices and a split mode where data traffic is split between the direct communication link and a relayed communication link via the at least one network access device; and

setting a communication mode for the two or more terminal devices accord-ing to the received recommendation for the sidelink coordination.

According to a third aspect, there is provided an apparatus comprising means for performing:

receiving, at a terminal device from an access device of a network, a config uration command which indicates a direct mode where data traffic is transmitted via a direct communication link between the terminal device and a neighbouring terminal device, or a split mode where data traffic is split between the direct com munication link and a relayed communication link via the network access device; and

performing a link setup in accordance with the received configuration com mand, wherein the data traffic is split or merged according to the split mode or directed to the direct communication link according to the direct mode.

According to a fourth aspect, there is provided an apparatus comprising: a receiving circuitry configured to receive from at least one network access device measurement reports about communication links at two or more terminal devices;

a deriving circuitry configured to derive from the received measurement re ports at least one recommendation for a sidelink coordination at the two or more terminal devices, wherein the sidelink coordination determines at least one of a direct mode where data traffic is transmitted via a direct communication link be tween terminal devices and a split mode where data traffic is split between the direct communication link and a relayed communication link via the at least one network access device; and

a signalling circuitry configured to signal the at least one recommendation to the at least one network access device.

According to a fifth aspect, there is provided an apparatus comprising: a receiving circuitry configured to receive at a network access device at least one recommendation for a sidelink coordination at two or more terminal devices, wherein the sidelink coordination determines at least one of a direct mode where data traffic is transmitted via a direct communication link between terminal devices and a split mode where data traffic is split between the direct communication link and a relayed communication link via the at least one network access device; and a setting circuitry configured to set a communication mode for the two or more terminal devices according to the received recommendation for the sidelink coordination.

According to a sixth aspect, there is provided an apparatus comprising: a receiving circuitry configured to receive, at a terminal device from an ac cess device of a network, a configuration command which indicates a direct mode where data traffic is transmitted via a direct communication link between the termi nal device and a neighbouring terminal device, or a split mode where data traffic is split between the direct communication link and a relayed communication link via the network access device; and

a link setup circuit configured to perform a link setup in accordance with the received configuration command, wherein the data traffic is split or merged accord ing to the split mode or directed to the direct communication link according to the direct mode.

According to a seventh aspect, there is provided a method comprising: receiving from at least one network access device measurement reports about communication links at two or more terminal devices;

deriving from the received measurement reports at least one recommenda tion for a sidelink coordination at the two or more terminal devices, wherein the sidelink coordination determines at least one of a direct mode where data traffic is transmitted via a direct communication link between terminal devices and a split mode where data traffic is split between the direct communication link and a relayed communication link via the at least one network access device; and

signalling the at least one recommendation to the at least one network ac cess device.

According to an eighth aspect, there is provided a method comprising: receiving at a network access device at least one recommendation for a sidelink coordination at two or more terminal devices, wherein the sidelink coordi nation determines at least one of a direct mode where data traffic is transmitted via a direct communication link between terminal devices and a split mode where data traffic is split between the direct communication link and a relayed communication link via the at least one network access device; and

setting a communication mode for the two or more terminal devices accord ing to the received recommendation for the sidelink coordination.

According to a ninth aspect, there is provided a method comprising:

receiving, at a terminal device from an access device of a network, a config uration command which indicates a direct mode where data traffic is transmitted via a direct communication link between the terminal device and a neighbouring terminal device, or a split mode where data traffic is split between the direct com munication link and a relayed communication link via the network access device; and

performing a link setup in accordance with the received configuration com mand, wherein the data traffic is split or merged according to the split mode or directed to the direct communication link according to the direct mode.

According to a tenth aspect, there is provided a computer program product comprising instructions for causing an apparatus to perform at least the following: receiving from at least one network access device measurement reports about communication links at two or more terminal devices;

deriving from the received measurement reports at least one recommenda tion for a sidelink coordination at the two or more terminal devices, wherein the sidelink coordination determines at least one of a direct mode where data traffic is transmitted via a direct communication link between terminal devices and a split mode where data traffic is split between the direct communication link and a relayed communication link via the at least one network access device; and

signalling the at least one recommendation to the at least one network ac cess device.

According to an eleventh aspect, there is provided a computer program product comprising instructions for causing an apparatus to perform at least the following:

receiving at a network access device at least one recommendation for a sidelink coordination at two or more terminal devices, wherein the sidelink coordi nation determines at least one of a direct mode where data traffic is transmitted via a direct communication link between terminal devices and a split mode where data traffic is split between the direct communication link and a relayed communication link via the at least one network access device; and

setting a communication mode for the two or more terminal devices accord ing to the received recommendation for the sidelink coordination.

According to a twelfth aspect, there is provided a computer program product comprising instructions for causing an apparatus to perform at least the following: receiving, at a terminal device from an access device of a network, a config uration command which indicates a direct mode where data traffic is transmitted via a direct communication link between the terminal device and a neighbouring

terminal device, or a split mode where data traffic is split between the direct com munication link and a relayed communication link via the network access device; and

performing a link setup in accordance with the received configuration com mand, wherein the data traffic is split or merged according to the split mode or directed to the direct communication link according to the direct mode.

In a first example, the recommendation of the apparatus of the first or fourth aspects or the method of the seventh aspect or the computer program product of the tenth aspect may comprises at least one quality of service configurations and resource allocations for the two or more terminal devices.

In a second example which may be combined with the first example, the communication links of the measurement reports of the apparatus of the first or fourth aspects or the method of the seventh aspect or the computer program prod uct of the tenth aspect may include direct communication links and relayed com munication links.

In a third example which may be combined with the second example, the sidelink coordination of the apparatus of the first or fourth aspects or the method of the seventh aspect or the computer program product of the tenth aspect may de termine a cellular mode where data traffic is transmitted via the relayed communi cation link via the at least one network access device.

In a fourth example which may be combined with any of the first to third examples, the means of the apparatus of the first aspect or the circuits of the ap paratus of the fourth aspect or the method of the seventh aspect or the computer program product of the tenth aspect may be provided in a radio access network function or an application layer function.

In a fifth example, which may be combined with any of the first to fourth examples, the means of the apparatus of the first aspect or a request circuit of the apparatus of the fourth aspect or the method of the seventh aspect or the computer program product of the tenth aspect may be configured to request the measure ment reports from the at least one network access device for a predetermined pair of terminal devices or a predetermined set of terminal devices.

In a sixth example, which may be combined with any of the first to fifth ex amples, the means of the apparatus of the first aspect or an optimization circuit of the apparatus of the fourth aspect or the method of the seventh aspect or the com puter program product of the tenth aspect may be configured to solve an optimiza tion problem in order to derive the at least one recommendation.

In a seventh example, which may be combined with any of the first to sixth examples, the means of the apparatus of the first aspect or a selection circuit of the apparatus of the fourth aspect or the method of the seventh aspect or the computer program product of the tenth aspect may be configured to define a controlling net work access device which relays signalling towards a terminal device associated with another network access device.

In an eighth example, which may be combined with any of the first to seventh examples, the means of the apparatus of the first aspect or a determination circuit of the apparatus of the fourth aspect or the method of the seventh aspect or the computer program product of the tenth aspect may be configured to determine based on the received measurement reports whether an optimal mode configura tion has been achieved, and to repeat a mode selection process until the optimal mode configuration has been achieved.

In a ninth example, which may be combined with any of the first to eighth examples, the means of the apparatus of the second aspect or a configuration cir cuit of the apparatus of the fifth aspect or the method of the eighth aspect or the computer program product of the eleventh aspect may be configured to configure a split sidelink radio bearer to set up the direct or split mode.

In a tenth example, which may be combined with any of the first to ninth examples, the means of the apparatus of the second aspect or a configuration cir cuit of the apparatus of the fifth aspect or the method of the eighth aspect or the computer program product of the eleventh aspect may be configured to configure the split sidelink radio bearer by a radio resource control function.

In an eleventh example, which may be combined with any of the first to tenth examples, the means of the apparatus of the second aspect or a creation circuit of the apparatus of the fifth aspect or the method of the eighth aspect or the computer program product of the eleventh aspect may be configured to create and dispose the split sidelink radio bearer in both terminal devices of the direct communication link.

In a twelfth example, which may be combined with any of the first to eleventh examples, the means of the apparatus of the second aspect or a setup circuit of the apparatus of the fifth aspect or the method of the eighth aspect or the computer program product of the eleventh aspect may be configured to set up a traffic split function for the split mode in a packet data conversion protocol layer.

In a thirteenth example, which may be combined with any of the first to twelfth examples, the means of the apparatus of the second aspect or a support circuit of the apparatus of the fifth aspect or the method of the eighth aspect or the computer program product of the eleventh aspect may be configured to use a con trol flow mechanism in each leg of the split sidelink radio bearer to support recom mended throughput or quality targets.

In a fourteenth example, which may be combined with the thirteenth exam ples, the means of the apparatus of the second aspect or the support circuit of the apparatus of the fifth aspect or the method of the eighth aspect or the computer program product of the eleventh aspect may be configured to use a radio link con trol buffer status reporting for the control flow mechanism.

In a fifteenth example, which may be combined with any of the first to four teenth examples, the means of the apparatus of the second aspect or a relay circuit of the apparatus of the fifth aspect or the method of the eighth aspect or the com puter program product of the eleventh aspect may be configured to relay data pack ets of a medium access control layer via the relayed communication link.

In a sixteenth example, which may be combined with any of the first to fif teenth examples, the means of the apparatus of the second aspect or a tunnel control circuit of the apparatus of the fifth aspect or the method of the eighth aspect or the computer program product of the eleventh aspect may be configured to tun nel the data traffic of the relayed communication link to another network access device by using a tunnelling protocol.

In a seventeenth example, which may be combined with any of the first to sixteenth examples, the direct communication link of the apparatus of the second or fifth aspects or the method of the eighth aspect or the computer program product of the eleventh aspect may comprise a sidelink connection or a WiFi connection.

In an eighteenth example, which may be combined with any of the first to seventeenth examples, the means of the apparatus of the third aspect or a split

and merge circuit of the apparatus of the sixth aspect or the method of the ninth aspect or the computer program product of the twelfth aspect may be configured to provide a split and merge function for mapping data packets of the data traffic in the direct communication link and the relayed communication link based on re ceived recommended scheduling weights.

In a nineteeth example, which may be combined with any of the first to eight eenth examples, the means of the apparatus of the third aspect or a reporting circuit of the apparatus of the sixth aspect or the method of the ninth aspect or the com puter program product of the twelfth aspect may be configured to provide measure ment reports about direct and relayed communication links to access device.

In a twenteeth example, which may be combined with any of the first to nine teenth examples, the means of the apparatus of the third aspect or a split control circuit of the apparatus of the sixth aspect or the method of the ninth aspect or the computer program product of the twelfth aspect may be configured to use the ac cess device as a secondary node for a split sidelink radio bearer.

In a twenty-first example, the means of the apparatus of the first to third aspects and all its examples may comprise:

at least one processor; and

at least one memory including computer program code, the at least one memory and computer program code configured to, with the at least one processor, cause the performance of the apparatus.

The computer program products of the seventh to ninth aspects may be stored on a medium or may be downloaded from a network.

A chipset may comprise the apparatus as described herein.

Brief Description of the Drawings

Some example embodiments will now be described with reference to the accompanying drawings in which:

Fig. 1 shows a schematic example of a wireless communication system where some example embodiments may be implemented;

Fig. 2 shows a scenario and functional overview of an example embodiment where involved terminal devices are in the coverage area of the same base station;

Fig. 3 shows a scenario and functional overview of an example embodiment with base station relay and cross-cell D2D communication;

Fig. 4 shows a scenario and functional overview of an example embodiment with a protocol stack example for relaying radio link control data packets in a radio node;

Fig. 5 shows a scenario and functional overview of an example embodiment with a protocol stack example for relaying media access control data packets in the radio node;

Fig. 6 shows a scenario and functional overview of an example embodiment with a protocol stack example for tunnelling data packets between two radio nodes;

Fig. 7 shows a message sequence chart for quality reporting, transmission mode recommendation and split bearer configuration according to a sample em bodiment;

Fig. 8 shows a flow diagram of a procedure for optimizing a mode configu ration according to a sample embodiment; and

Figs. 9A to 9C show diagrams with exemplary data rate characteristics achieved by enabling D2D communication for different system set-ups.

Detailed Description

The following describes in further detail some examples of systems, appa ratus and possible mechanisms for at least one of sidelink and infrastructure traffic offloading in a cellular network, such as a fifth generation (5G) cellular network. It is however noted that some embodiments may also be implemented in other sys tems, apparatus and possible mechanisms for other types of networks with sidelink or D2D communication options.

As discussed in the background section above, sidelink or D2D communi cation enables a shift towards more mesh-like communication topologies, which may provide interesting options for industrial, vehicular and sensor networks. Apart from this, also peer-to-peer applications may benefit from the sidelink or D2D op tions.

The current Release 15 standard (i.e. 3GPP (2018), TS 23.303“Proximity-based services (ProSe); Stage 2” V15 (Vol. 0)) does not specify how traffic will be handed off to sidelink, and it does not enable using infrastructure to optimize key performance indicators (KPIs) for quality of service (QoS).

An option to leverage a sidelink in a beneficial way may be to select traffic flows that should be offloaded to sidelink. Intuitively, two devices that are at spatially distant locations may not be able to maintain good communication quality via a sidelink, whereas they might strongly benefit if the source and target devices are near each other. However, even when sidelinks achieve a minimum communication quality, it can still make sense to use uplink-downlink communication nevertheless. A reason may be that using a‘too bad’ sidelink can degrade communication of other concurrent links by consuming many resources. In fact, all traffic flows, be they sidelink, uplink or downlink, may be coupled via common transmission re sources. As an example, they may be coupled by at least one of a scheduling strat egy used by the operator and underlying physical layer capabilities. The problem of choosing the right traffic flows to use the sidelink is in general non-trivial and may be called“mode selection problem”.

Apart from the mode selection problem itself, the design of a good handoff procedure may be desirable. A‘good’ procedure thereby should be applicable to a variety of underlying systems, i.e., to devices with heterogeneous capabilities, re source structures and scheduling functions, while still leaving options of making reasonable decisions to reach a‘good’ or favourable network state.

In some example, handoff may be tackled from a cross-layer optimization perspective. It may be part of an overall decision framework including at least one of scheduling and physical layer parameter choices. Also, it may be assumed that sidelinks operate in a semi-persistent fashion, i.e., they may use a single carrier for the whole or at least some duration of communication. Moreover, existing handoff procedures may be tailored to a specific system setup and/or may incorporate spe cialized scheduling and/or signaling procedures among the nodes.

A general handoff procedure may be provided without exactly specifying in terfaces or, alternatively, offloading procedures may be tailored to specific use cases, which may incorporate specialized signalling structures. As another option, a generalized handoff procedure may be provided that is applicable to a variety of underlying system configurations. The handoff procedure may for example reside on higher protocol layers. It may then not require any signalling that depends on

the exact system. It may be used to make reasonable handoff decisions, i.e., to optimize the system configuration to a variety of objectives.

According to some examples described hereinafter, methods, apparatus, and systems for dynamically switching traffic towards and away from a sidelink are provided. This may allow at least one of handoff of traffic to a sidelink, re-integration of sidelink traffic into conventional uplink-downlink communication and concurrent multi-path connection using both, sidelink and uplink-downlink path for data transport. As a further option, performance monitoring of such traffic by the network (e.g. the radio access network (RAN) may be possible, which can be leveraged for making appropriate hand-off decisions.

Fig. 1 schematically shows a schematic example of a wireless communica tion system where some example embodiments may be implemented. The de picted exemplary RAN of the wireless communication system comprises a plurality of terminal devices (e.g. UEs) 101 to 105, which are termed“UE1” to“UE5”.

Although in the example of Fig. 1 six terminal devices are shown, it will be understood that in other examples more or fewer terminal devices may be present.

The terminal devices form the endpoints of sidelink traffic between them. For simplicity, a two-terminal network is considered in the following, where the source terminal is termed“UE 1”, while the target terminal is termed“UE 2”. Extension to multiple terminal pairs follows later.

Furthermore, two base stations 108 and 109 are shown, which are termed “BS1” and“BS2”. Each base station is the main anchor point or serving base station for all mobile communications in its respective defined cell. In the example of Fig. 1 , the first base station (BS1 ) 108 currently serves three terminal devices 101 to 103 (UE1 to UE3) located in the coverage area or cell of the first base station 108. Furthermore, the second base station (BS2) 109 serves two terminal devices 104 and 105 (UE4 and UE5) currently located in the coverage area or cell of the second base station 109. Examples of such base stations could be a node B (“eNB” or “eNodeB” in 4G terminology,“gNB” or“gNodeB” in 5G terminology) or indeed any other type of access device, a small cell or similar.

Additionally, a sidelink coordination function (SCF) 1 10 is provided, which could be located at one or more of the base stations 108 and 109, in a co-located data center or at any other location within RAN.

According to some examples, the SCF 1 10 is configured to control the base stations and terminal devices to achieve an optimized transmission mode selection of terminal devices capable of direct D2D communication (e.g. sidelink communi cation). In an example, an enhanced split radio bearer structure is proposed for enabling dynamic connectivity between two devices, potentially relayed over the radio network.

It is assumed that two neighboring ones of the terminal devices 101 to 105 are in mutual proximity and have become aware of their proximity, e.g., by a prox imity alert or any other kind of neighbour detection process. There are a set of neighbor discovery procedures, which involve regular transmission of beacons by the terminal devices ("beaconing"), in which they advertise their presence and D2D capable services. These procedures are expected to be triggered in reaction to a proximity alert, to verify proximity. Another option could be to trigger a process of mutual detection via a serving base station or even via some location service. For the latter, the terminal devices101 to 105 need to be capable of some kind of signal exchange. In an exemplary setup, the SCF 1 10 may trigger a configuration of the terminal devices 101 to 105 by recommending the respective serving base station to install, tear down or alter a new type of bearer, called“split sidelink radio bearer” (SSRB).

According to some examples, the SSRB may be configured to support at least two of three transmission modes, which comprise a direct mode (DM), a cel lular mode (CM) and a split mode (SM). For CM and SM, the respective base sta tion (e.g. BS1 108 in Fig. 1 ) forwards traffic originating from the source terminal (e.g. UE1 101 in Fig. 1 ) towards the target terminal (e.g. UE 2 in Fig. 1 ).

According to some examples, depending on the set-up, the traffic may also pass a second base station (e.g. BS2 109 in Fig. 1 ), if the source and target termi nals reside in different cells. Traffic is transported from the source terminal e.g. UE1 101 in Fig. 1 ) to the first base station (e.g. BS1 108 in Fig. 1 ) via a normal uplink channel (e.g., a radio link control (RLC) channel), which may be pre-defined de pending on the used type of standard. The uplink channel may merely act as a tunnel to interface a connection of a packet data convergence protocol (PDCP) layer between the source terminal (e.g. UE1 101 in Fig. 1 ) and the first base station (e.g. BS1 108 in Fig. 1 ).

According to some examples, the SCF 1 10 may signal recommendations for transmission mode and QoS parameters used for a sidelink channel to the base station.

Furthermore, according to some examples, the SCF 1 10 may request from the base station 108, 109 measurement reports for a specific one or for a set of the terminal devices 101 to 105.

Fig. 2 shows a scenario and functional overview of an example embodiment where terminal devices UE1 and UE2 are in the coverage area of the same base station BS1 and a further terminal UE 3 is in the coverage area of a second base station BS2.

According to some examples, the terminal devices UE1 and UE2 may use direct (e.g., sidelink, WiFi, etc.) communication to other terminal devices as alter native to or in conjunction with network-based communication via the base station BS to enable optimized communication in terms of QoS, throughput, packet error rate, reliability, latency, interference or any other parameters that determine trans mission quality.

According to some examples, the SCF may use measurements or estimates in different modes for coordinating transmission mode selection of the terminal de vices UE1 and UE2.

According to some examples, the terminal devices UE1 and UE2 may be configured to report measurements on both sidelink and base station channels, including QoS or other quality metrics like PDCP or other throughput measures during communication.

According to some examples, measuring the achieved throughput may be provided as a minimum configuration.

According to some examples, other valid metrics such as queue backlog, packet error rate or delay may be configured in the alternative or in addition.

According to some examples, estimates of achievable quality (e.g. QoS) may be provided by the base station BS to the SCF. Such estimates may for ex ample depend on at least one of available channel measurements, used scheduling policies or similar.

According to some examples, the SCF may be implemented as a RAN func tion or an application layer function, e.g., co-located with proximity-based service (ProSe) function, or both.

According to some examples, the SCF may provide a recommendation to the base station BS, which transmission mode shall be used by which of the termi nal devices UE1 and UE2. As already indicated above, possible transmission modes may include DM (which is direct D2D communication via a sidelink channel or WiFi connection or another suitable connection), CM (where the communication between the terminal devices UE1 and UE2 is relayed over one or more base sta tions), and SM (a combination of DM and CM, where a terminal device may decide based on an indicator (e.g. a weight indicator) provided by the SCF or based on flow control or based on another suitable parameter, how traffic shall be split be tween the direct D2D link and the base station link).

Alternatively or additionally, in some examples, the traffic may be duplicated on both channels in the split mode in order to increase the reliability of the commu nication between both terminal devices UE1 and UE2.

According to some examples, the SCF may additionally or alternatively pro vide recommendations on resource allocation for sidelink terminal devices.

According to some examples, the SSRB may terminate at two terminal de vices (e.g. UE1 and UE2 in Fig. 2) which are eligible for DM and CM communica tion. The SSRB may be uni- or bidirectional. A uni-directional SSRB may allow dif ferent configurations for both communication directions.

According to some examples, a traffic split function may be provided in the PDCP layer. In each communication direction, a base station leg of the SSRB may be relayed by the base station BS towards the receiving terminal device (e.g. UE1 or UE2 in Fig. 2). At both transmitting (e.g. source) and receiving (e.g. target) ter minals a traffic split and merge function may for example be provided, as shown in Fig. 2).

According to some examples, a radio resource control (RRC) function in the controlling base station BS may create and dispose the SSRB in both source and target terminals.

According to some examples, at least one of minimum and maximum throughput targets may be defined for each active leg of the SSRB. Other QoS targets may also be set, if configured and applicable.

According to some examples, a flow control mechanism may be used on each leg of the SSRB to support the defined throughput, quality or other targets. As an example, an RLC buffer status reporting can be utilized for this.

In the case two terminal devices (e.g. UE1 and UE3 in Fig. 2) are not asso ciated to the same base station, but rather to two different base stations BS1 and BS2, the traffic may be transferred via a base station to base station interface (BS-BS interface), as explained below in more detail with reference to Fig. 3.

Fig. 3 shows a scenario and functional overview of an example embodiment with base station relay and cross-cell D2D communication.

In the case of Fig. 3, both terminal devices UE1 and UE2 are not associated to the same base station, but rather to two different base stations BS1 and BS2. User data or traffic is transferred via a base station to base station interface (e.g., X2/Xn interface in NG-RAN or another BS-BS interface in another standard).

According to some examples, in case the SSRB is configured to traverse several base stations (e.g. BS1 and BS2 in Fig. 3), the SCF may select and define a controlling base station (e.g. BS1 in Fig. 3), which is configured to relay signalling and/or traffic towards the terminal device (e.g. UE2 in Fig. 3) associated with the other base station (e.g. BS2 in Fig. 3).

In the following, different exemplary configurations and protocol stack alter natives for the split mode (SM) are explained based on an exemplary 5G network architecture with reference to Figs. 4 to 6. They may for example be implemented for the user plane based on the current 3GPP Release 15 standard.

A plane, in a networking context, may be one of three components of a tel ecommunications architecture. These three components may be the user plane, a control plane and a management plane. They can be thought of as different areas of operations. Each plane may carry a different type of traffic and may conceptually (and often in reality) be an overlay network (i.e. a telecommunications network that runs independently on top of another one, although supported by its infrastructure).

The user plane (sometimes known as the data plane, forwarding plane, car rier plane or bearer plane) may carry network user traffic. The control plane organ izes establishment, release of connections according to operator and end-user’s QoS and security requirements, checks the user’s authorisation/authentication and provides information needed for accounting/billing of the used services. The control plane may carry signalling traffic between control functions that are located at dif ferent devices and/or network nodes to coordinate these control tasks. The man agement plane, which may carry administrative traffic, may be considered a subset of the control plane.

According to some examples, the setup may consist of one or two radio ac cess nodes (e.g. base stations, such as gNBs or eNBs) and two terminal devices UE1 and UE2 where data from a source terminal UE1 needs to be transported to a sink terminal UE2.

Note that Figs. 4 to 6 show a split mode user plane because the split mode user plane consists of cellular mode and direct mode user planes.

A bearer service may be a link between two points, which is defined by a certain set of characteristics. When a terminal device shall be provided with any service, the service may be associated with a bearer specifying the configuration for associated protocol layer(s) (e.g. physical layer and layer 2) of a protocol stack in order to have its QoS clearly defined. A bearer may thus be considered as a channel offered by the associated protocol layer(s) to higher protocol layers for the transfer of user or control data. In other words, the associated protocol layer(s) offer(s) to the upper protocol layers the service of information transmission between the terminal device and the RAN by means of bearers. Therefore, a bearer may be a service access point between the associated protocol layer(s) and the upper pro tocol layers.

As an example, the 5G protocol stack comprises layer 1 , layer 2 and layer 3.

The 5G layer-1 corresponds to the physical layer. Functions of the physical (PFIY) layer may include error detection on the transport channel and indication to higher layers, forward error control (FEC) encoding/decoding of the transport chan nel, hybrid automatic repeat request (HARQ) soft-combining, rate matching of the coded transport channel to physical channels, mapping of the coded transport

channel onto physical channels, power weighting of physical channels, modulation and demodulation of physical channels, frequency and time synchronisation, radio characteristics measurements and indication to higher layers, multiple input multi ple output (MIMO) antenna processing, transmit diversity (TX diversity), digital and analog beamforming, and radio frequency (RF) processing.

The 5G layer-2 comprises MAC, RLC and PDCP sublayers.

Functions of the MAC sublayer may include beam management, random access procedure, mapping between logical channels and transport channels, con catenation of multiple MAC service data units (SDUs) belonging to one logical channel into a transport block (TB), multiplexing/demultiplexing of 5G-MAC SDUs belonging to one or different logical channels into/from transport blocks (TB) deliv ered to/from the physical layer on transport channels, scheduling information re porting, error correction through FIARQ, priority handling between logical channels of one terminal device, priority handling between terminal devices by means of dy namic scheduling, transport format selection, and padding.

Functions of the RLC sublayer may include transfer of upper layer PDUs, error Correction through ARQ, reordering of 5G-RLC data PDUs, duplicate detec tion, protocol error detection, 5G-RLC SDU discard, segmentation/resegmentation, 5G-RLC re-establishment.

Functions of the PDCP sublayer may include transfer of user data, in-se quence delivery of upper layer PDUs at 5G-PDCP re-establishment procedure for 5G-RLC, duplicate detection of lower layer SDUs at 5G-PDCP re-establishment procedure for 5G-RLC, retransmission of 5G-PDCP SDUs at mobility in connected mode for 5G-RLC, ciphering and deciphering, timer-based SDU discard in uplink, ciphering and integrity protection and transfer of control plane data.

The 5G layer-3 corresponds to the RRC layer. Functions of the RRC layer may include broadcasting of system information, establishment, maintenance and release of RRC connections, security including key management, establishment, configuration, maintenance and release of point-point radio bearers, mobility func tions along with cell addition and cell release, terminal device measurement report ing, control of terminal device reporting, terminal based mobility, and direct mes sage transfer to/from network from/to terminal device.

According to some examples, in the direct mode (DM), a bearer is configured for direct data transport via a sidelink connection, or some other means like a WiFi link for example.

According to some examples, in the cellular mode (CM), the source terminal UE1 transmits traffic intended for the target terminal UE2 to the radio node (e.g. base station such as gNB or eNB) which relays directly to the target terminal UE2. ARQ may then be terminated in the respective RLC protocol entity of the terminal device.

According to some examples, the split-mode (SM) combines CM and DM, as is shown in the Figs. 4 to 6. A traffic split and merge function at the terminal device may be responsible for mapping data packets on the direct link and the cellular channel. The traffic split and merge function may for example be based on scheduling weights recommended by the SCF and set by an RRC protocol entity at the radio node (e.g. base station such as gNB or eNB or another access node) or based on flow control feedback.

Fig. 4 shows a scenario and functional overview of an example embodiment with a protocol stack example for relaying RLC data packets (e.g. RLC-SDUs) in a radio node (e.g. a gNodeB (gNB) in this example).

The RLC data packets are forwarded by the radio node from the source ter minal UE1 to the sink terminal UE2. In an RLC acknowledged mode, when the RLC data packets got delivered successfully over the source-side and the sink-side RLC channel, then the final RLC acknowledgement for an RLC data packet is sent to the source terminal UE1 . The RLC acknowledged mode feedback, i.e. the indica tion about successful delivery of RLC data packets to the target terminal UE2 may be transferred from sink side processing to source side processing of a relaying functionality at the radio node.

According to some examples, in the split mode there may be an alternative for the source terminal UE1 to request a PDCP packet delivery report via the direct branch of the split mode bearer.

Fig. 5 shows a scenario and functional overview of an example embodiment with a protocol stack example for relaying MAC data packets (e.g. MAC-SDUs) in the radio node (e.g. gNodeB in this example).

In the exemplary scenario of Fig. 5, the MAC data packets are relayed by the radio node. This means the RLC channels are not terminated in the radio node and therefore no special handling with respect to delivery feedback handling is nec essary at the radio node. However, according to some examples, a special feed back coordination functionality may now be necessary for the MAC layer.

Fig. 6 shows a scenario and functional overview of an example embodiment with a protocol stack example for tunnelling data packets between two radio nodes (e.g. base stations such as eNB or gNB or other access nodes).

In the exemplary scenario of Fig. 6 two radio nodes (e.g. gNBs in this exam ple) are involved. According to some examples, the radio nodes may be connected via an Xn interface or any other type of interface suitable for establishing an inter connection between two access devices. RLC data packets and delivery indica tions may then be tunnelled in respective opposite directions between the radio nodes by using a suitable tunnelling protocol, such as the GPRS user plane tun nelling protocol (GTP-U) or the Xn user plane protocol (Xn-U), as indicated in Fig. 6.

According to some examples, the protocol stack of the tunnelling function may comprise an L1/L2 layer, UDP/IP layer and GTP-U layer on top of each other. Other options could be generic routing encapsulation (GRE) or the base station could act as a L2 switch or bridge, so that L2 data could be directly encapsulated (e.g., as LAN frames).

Fig. 7 shows a message sequence chart for quality reporting, transmission mode recommendation and split bearer configuration according to a sample em bodiment, wherein time proceeds from the top to the bottom of the chart.

As is shown in Fig. 7, according to some examples, the SCF may fist initiate in step 1 a quality reporting procedure where quality (QoS) parameters that have been measured at the terminal devices UE1 and UE2, or estimates of the achiev able quality, which may be requested by the SCF. Upon receiving a respective command from the SCF, the radio node (e.g. a gNB in this example, or any other base station or radio access device) fetches the currently achieved quality (QoS) values from the terminal devices UE1 and UE2, or calculates estimates of the achievable quality, and provides them to the SCF.

According to some examples, in step 1 , the radio node may provide a QoS report for UE-UE communication to the SCF, including some UE identifier.

As an example, for identification of the terminal devices UE1 and UE2 a unique identifier may be used, such as a cell radio network temporary identifier (C-RNTI), an application layer user ID (ALUID) or an evolved packet core (EPC) ProSe User ID (EPUID). e.g. C-RNTI/ALUID/EPUID.

According to some examples, the measurement provisioning may be peri odic with some configured time interval, originated from the radio node based on some thresholds for UE measurements, or based on a request by the SCF.

Then, the SCF may initiate a mode recommendation procedure where trans mission mode and QoS configuration recommendations can be optimized at the SCF, as shown in step 2 of Fig. 7. As an example, the SCF may derive recommen dations for terminal transmission modes, QoS settings and QoS measurement set tings, which may all be controlled by the radio node.

Then, in step 3, the recommendations may be indicated to the radio node by a corresponding message. The SCF may for example provide recommendations where the terminal devices UE1 and UE2 are identified by the identifier provided in step 1 .

According to some examples, the recommendations in this message may for example refer to a specific terminal pair or to a set of terminal pairs.

Thereafter, the SCF may initiate a split bearer management procedure where the radio node may set, reconfigure or tear down the split bearer (i.e, SSRB) of each terminal pair in the network. The split bearer management procedure is shown by steps 4 to 9 in Fig. 7.

In steps 4 and 6, the radio node initiates SSRB configuration at the terminal devices UE1 and UE2 e.g. by transmitting respective configuration command (e.g. RRC connection reconfiguration messages which may indicate an SSRB setup, a transmission mode and scheduling weights).

According to some examples, the radio node may send the configuration command with a modified cell group configuration field (e.g. rlc-BearerToAdd-ModList field) to establish the split bearer (i.e. SSRB). Additionally, a key for user plane encryption and integrity protection may be included in the message.

In steps 5 and 7, the terminal devices UE1 and UE2 may each respond with a respective completion message (e.g. RRC reconfiguration complete message) upon successful bearer establishment.

According to some examples, the configuration command may include at least one of a targeted mode (e.g. DM, CM or SM) and QoS parameters.

Then, in step 8, the RLC relay between source and target terminals UE1 , UE2 may be setup. For CM, the radio node may prepare all affected radio nodes for relaying in step 8.

According to some examples, the radio node may configure RLC relay(s) between the terminal devices UE 1 and UE 2, if necessary. The UEs identifiers may be used for forwarding RLC data packets (e.g. RLC-PDUs).

Finally, in step 9 the source terminal UE1 may be notified by the radio node that the setup procedure has been finished (e.g. by a SSRB setup complete mes sage).

After the split bearer (i.e. SSRB) has been set-up, the terminal devices UE1 and UE2 may undergo in step 10 further standard procedures for entirely setting up the uplink/downlink and/or the direct link communication. These may include layer 3 address exchange, key exchange etc., and may differ depending on whether the communication is relayed over several radio nodes (e.g. base stations (eNBs or gNBs) or other access devices), over WiFi or via a sidelink connection, respectively. An example may also be a link-local IPv6 procedure.

The proposed procedure of Fig. 7 may thus provide an optimization of direct communication usage over different underlying system settings.

According to some examples, a single LTE cell with an eNodeB as base station and a fixed number of potential D2D links may be considered, for which a mode selection procedure shall be performed. The base station may be deployed at the center of the cell, while for each D2D link, two nodes (e.g. terminal devices, UEs) may be placed within a maximum radius of the base station and a maximum distance of one another.

The network may have a resource grid of six 180 kHz frequency channels available, that are accessed in a Time Division Duplex (TDD) manner with six time slots of 1 ms available in the uplink frame and four time slots in the downlink frame. Both, uplink and downlink frames may be accessed arbitrarily by the D2D links, if an involved scheduler allocates the resources accordingly. Channels may be gen erated according to the Winner-ll channel model, which takes into account the dis tance based path loss, line-of-sight probability and shadowing, based on the de vices’ antenna heights. For each potential link of source terminal to base station, base station to destination terminal or the D2D source-destination pair, the receiver Signal to Interference and Noise Ratio (SINR) may be determined for fixed trans mission powers. The determined SINR may then be mapped to a maximum-rate modulation and coding scheme (MCS), choosing among LTE MCS, which range from Quadrature Phase Shift Keying (QPSK) to 64-Quadrature Amplitude Modula tion (QAM). The chosen MCS may be assumed to be used whenever the scheduler assigns that resource to the link, respectively.

According to some examples, each source node may run a transport-layer congestion control mechanism, deciding on how much traffic is admitted into a MAC-layer queue. The congestion control mechanism may aim at proportional fair throughput maximization, to avoid cases where all resources are assigned to a sin gle link with good channel quality, while other links get zero rate.

Fig. 8 shows a flow diagram of a procedure for optimizing a mode configu ration according to a sample embodiment.

Initially, in step SO, the SCF is provided with measurement reports and/or estimations as baseline. They may have been provided e.g. by channel quality in dicators (CQI) of involved links. Then, in step S1 , the SCF determines an optimal mode choice and/or rate target(s) according to its initial knowledge, e.g., by solving an optimization problem. In the following step S2, the mode choice and/or rate tar gets) of the SCF are recommended (i.e. signalled) to a base station (BS), such as an eNodeB or gNobeB or any other access node or radio node, which enforces them in step S3 e.g. by setting communication modes for terminal links. In the sub sequent step S4, the base station waits a predetermined number of frames and then reports the actual rates back to the SCF. Then, in step S5, the SCF takes the feedback (i.e. actual rates) received from the base station into account and deter mines whether it should re-iterate the procedure. The re-iteration can depend on, e.g., whether QoS is sufficient (not necessarily optimal), or whether a maximum number of iterations has been reached. The sufficiency of QoS may be based on

reported quality metrics (e.g. throughput, latency, reliability and/or interference pa rameters, or the like). The reported quality metrics may be of the same type as the ones based on which the original recommendation in step S2 was determined.

If the SCF decides in step S6 that another iteration is initaited, the proce dures branches to step S6 and the SCF solves an improved optimization problem, taking into account the new feedback received from the base station. Then, steps S2 to S5 are repeated. Otherwise, no new recommendations are done and the proceeds stops..

Accordingly, the proposed mode configuration optimization procedure can be repeated, until an optimal mode configuration has been found.

Figs. 9A to 9C show diagrams with exemplary data rate characteristics achieved by enabling D2D communication for different system set-ups.

Three different scenarios are considered here. In the first one, called“Over lay D2D”, a backpressure scheduler assigns transmission resources e.g. based on at least one of queue back-logs and traffic. Resources may be assigned exclusively to one link here. Such a backpressure scheduler may take the buffer states of all nodes as an input, which are reported, e.g., by buffer status reports (BSRs), and knowledge on achievable data rates, e.g., channel quality index (CQI). Then, it cal culates a "backpressure" value based on the differential backlog of each hop, i.e., the transmitter backlog minus the receiver backlog, and uses these as weights to prioritize links, where links with larger differential backlog have larger priority. Based on these values, the backpressure scheduler may determine a schedule by solving a weighted sum-rate maximization problem.

In the second one, called“Underlay D2D”, the same backpressure scheduler allows frequency reuse by sidelinks connections with fixed transmission powers. This may be realized by letting all links interfere at the beginning and measuring the achieved SINR values. The resulting SINR values may again be mapped to the selected MCS and used in the course of further scheduling. In the third one, called “Outband D2D”, direct communication may be realized over WiFi, using at least one of carrier sense multiple access with collision avoidance (CSMA/CA) and ex ponential back-off rule.

In the diagrams of Figs. 9A to 9C results are shown for two to eight links, where the y-axis shows the total achieved data rate. Compared is a greedy cellular mode (Greedy CM) and a greedy direct mode (Greedy DM), where all links use CM or DM irrespective of their direct channels, and a version that is optimized for a fair distribution of data rates (Optimum Fair). In "greedy" mode selection strategies, the links are forced to use the CM/DM whenever a non-zero rate can be achieved in the respective leg.

As can be gathered from the characteristics of Figs. 9A to 9C, DM creates larger data rates than CM, which is due to its better channels. The optimized ver sion achieves less data rates for overlay and underlay communication. Flere, parts of the achievable rate are sacrificed to achieve a fairer rate distribution.

It may thus be concluded that the proposed offloading procedures can be used to optimize network towards a desired metric, irrespective of how the direct link is actually realized.

According to some examples, a split bearer may thus be used for optimized D2D communication which may be configured by a radio resource control function of a base station.

According to some examples, a sidelink coordination function may be intro duced, that determines at least one of an optimal mode and QoS configurations for eligible terminal devices.

According to some examples, the SCF may then coordinate across several base stations to improve at least one of inter-site interference and overall radio resource utilization. Via a respective interface, current QoS parameters achieved by the flow associated with the bearer, or estimates thereof, may be exposed to the SCF by the base station. The terminal device may then utilize the base station as a secondary node for the bearer, or in a split-mode fashion. The base station may for example relay traffic to another base station to complement inter-site direct de-vice-to-device communication.

In general, the various example embodiments and examples may be imple mented in hardware or special purpose circuits, software, logic or any combination thereof. Some aspects of the invention may be implemented in hardware, while other aspects may be implemented in firmware or software which may be executed by a controller, microprocessor or other computing device, although the invention is not limited thereto. While various aspects of the invention may be illustrated and described as block diagrams, flow charts, or using some other pictorial representa tion, it is well understood that these blocks, apparatus, systems, techniques or methods described herein may be implemented in, as non-limiting examples, hard ware, software, firmware, special purpose circuits or logic, general purpose hard ware or controller or other computing devices, or some combination thereof.

As used in this application, the term“circuitry” may refer to one or more or all of the following: (a) hardware-only circuit implementations (such as implemen tations in only analog and/or digital circuitry) and(b) combinations of hardware cir cuits and software, such as (as applicable): (i) a combination of analog and/or dig ital hardware circuit(s) with software/firmware and (ii) any portions of hardware pro cessors) with software (including digital signal processor(s)), software, and memory(ies) that work together to cause an apparatus, such as a mobile phone or server, to perform various functions) and (c) hardware circuit(s) and or proces sors), such as a microprocessors) or a portion of a microprocessors), that re quires software (e.g., firmware) for operation, but the software may not be present when it is not needed for operation. This definition of circuitry applies to all uses of this term in this application, including in any claims. As a further example, as used in this application, the term circuitry also covers an implementation of merely a hardware circuit or processor (or multiple processors) or portion of a hardware cir cuit or processor and its (or their) accompanying software and/or firmware. The term circuitry also covers, for example and if applicable to the particular claim ele ment, a baseband integrated circuit or processor integrated circuit for a mobile de vice or a similar integrated circuit in server, a cellular network device, or other com puting or network device. Some of the examples may be implemented by computer software executable by a data processor of the mobile device, such as in the pro cessor entity, or by hardware, or by a combination of software and hardware. Com puter software or program, also called program product, including software rou tines, applets and/or macros, may be stored in any apparatus-readable data stor age medium and they comprise program instructions to perform particular tasks. A computer program product may comprise one or more computer-executable com ponents which, when the program is run, are configured to carry out some of the examples. The one or more computer-executable components may be at least one software code or portions of it.

Further in this regard it should be noted that any blocks of the logic flow as in the Figs. 7 and 8 may represent program steps, or interconnected logic circuits, blocks and functions, or a combination of program steps and logic circuits, blocks and functions. The software may be stored on such physical media as memory chips, or memory blocks implemented within the processor, magnetic media such as hard disk or floppy disks, and optical media such as for example DVD and the data variants thereof, CD. The physical media is a non-transitory media.

The memory may be of any type suitable to the local technical environment and may be implemented using any suitable data storage technology, such as sem iconductor based memory devices, magnetic memory devices and systems, optical memory devices and systems, fixed memory and removable memory. The data processors may be of any type suitable to the local technical environment, and may comprise one or more of general-purpose computers, special purpose computers, microprocessors, digital signal processors (DSPs), application specific integrated circuits (ASIC), FPGA, gate level circuits and processors based on multi core pro cessor architecture, as non-limiting examples.

Some of the examples may be practiced in various components such as integrated circuit modules. The design of integrated circuits is by and large a highly automated process. Complex and powerful software tools are available for convert ing a logic level design into a semiconductor circuit design ready to be etched and formed on a semiconductor substrate.

The foregoing description has provided by way of non-limiting examples a full and informative description of exemplary embodiments. Flowever, various mod ifications and adaptations may become apparent to those skilled in the relevant arts in view of the foregoing description, when read in conjunction with the accompany ing drawings and the appended claims. Flowever, all such and similar modifications of the teachings of the described exemplary embodiments will still fall within the scope of this disclosure as defined in the appended claims. Indeed, there is a fur ther exemplary embodiment comprising a combination of one or more exemplary embodiments with any of the other exemplary embodiments previously discussed.