SRB CONFIGURATION

TECHNICAL FIELD

The present disclosure generally relates to communication networks, and more specifically to methods and devices for SRB configuration.

BACKGROUND _

New Radio (NR) sidelink (SL) communication was specified by 3GPP in Rel-16. The NR SL is an evolution of the Long Term Evolution (LTE) sidelink, in particular of the features introduced in Rel-14 and Rel-15 for V2X communication. Some of the most relevant features of the NR sidelink are the following:

• Support for unicast and groupcast transmissions, in addition to broadcast transmissions, which were already supported in LTE.

• Support for Hybrid Automatic Repeat request (HARQ) feedback over the SL for unicast and groupcast. This feedback is conveyed by the receiver user equipment (UE) to the transmitted UE using the physical sidelink feedback channel (PSFCH). This functionality is new in NR compared to LTE.

• To alleviate resource collisions among different sidelink transmissions launched by different UEs, it enhances channel sensing and resource selection procedures, which also lead to a new design of physical channels carrying the sidelink control information (SCI). The new design of the SCI simplifies coexistence between releases by grouping together all the information related to resource allocation (which is critical for coexistence) in a single channel with a robust, predefined format. Other control information is carried by other means, in a more flexible manner.

• Grant-free transmissions, which are supported in NR uplink transmissions, are also provided in NR sidelink transmissions, to improve the latency performance.

• To achieve a high connection density, congestion control and thus the Quality of Service (QoS) management is supported in NR sidelink transmissions.

In Rel-16, 3GPP introduced the sidelink for the 5G NR. The driving use-case bein vehicular communications with more stringent requirements than those that typically could be served by LTE SL. To meet these stringent requirements, NR SL can perform broadcast, groupcast, and unicast communications. In groupcast communication, the intended receivers of a message are typically a subset of the vehicles near the transmitter, whereas in unicast communication, there is a single intended receiver.

Both the LTE SL and the NR SL can operate with and without network coverage and with varying degrees of interaction between the UEs (user equipment) and the NW (network), including support for standalone, network-less operation.

In 3GPP Rel. 17, public safety was one of the most important use cases, which can benefit from the already developed NR sidelink features in Rel. 16. Therefore, 3GPP specified enhancements related to public safety use cases taking the NR Rel 16 sidelink as the baseline. Besides, in some scenarios public safety services need to operate with partial or w/o NW coverage, such as during indoor firefighting, forest firefighting, earthquake rescue, sea rescue, etc. where the infrastructure is (partially) destroyed or not available, therefore, coverage extension is a crucial enabler for public safety, for both services communicated between UE and cellular NW and that communicated between UEs over sidelink. In Rel. 17, a SID on NR sidelink relay (RP-193253) was introduced which aims to further explore coverage extension for sidelink-based communication, including both UE to NW relay for cellular coverage extension and UE to UE relay for sidelink coverage extension. Now the work has proceeded to normative phase and in the WID only UE to NW relay is considered. In addition to public safety use-cases, the NR sidelink relay WI is also designed to support other commercial use-cases which would also greatly benefit from the coverage extension. Two solutions for UE to NW relaying were specified namely Layer-2 (L2) UE-to-NW relaying and Layer-3 (L3) UE-to-NW relaying.

In 3GPP RAN plenary [1], discussions were initiated in RAN 94 to identify the detailed motivations and work areas for the evolution of NR SL and NR SL relays in Rel-18. For NR SL relays, support for a multi-path operation with relays was agreed for its potential to improve the reliability/robustness as well as throughput. In a multi-path operation with relays, a UE is connected to the network via both a direct (UE-^ Network (gNB + CN) ) path and over an indirect path (UE-^ Relay UE-^ Network (gNB + CN)). In the direct path, the UE communicates with the gNB over a Uu interface. In the indirect path, the UE communicates with the relay UE over the sidelink PC5 interface and the relay UE communicates with the gNB over the Uu interface i.e., the UE communicates with the gNB indirectly via the PC5 and Uu interface over a single hop. The multi-path operation offers the UE a choice to perform transmission either over the direct path or over the indirect path or over both the direct and indirect path allowing for transmission flexibility. Multi-path operation is illustrated in Figure 1.

SUMMARY

In view of the above problem, the embodiments herein propose methods, network devices, computer readable mediums and computer program products for SRB configuration.

According to a first aspect of the present disclosure, there is provided a method implemented by a first user equipment (UE) for SRB configuration according to one or more embodiments of the present disclosure. The first UE may establish a signaling radio bearer (SRB) with the first network device to transmit a RRC signaling message on the SRB. The first UE may set an SRB configuration for the SRB. The first UE may transmit the Radio Resource Control (RRC) signaling message on the SRB using the SRB configuration to the first network device.

According to a second aspect of the present disclosure, there is provided a method implemented by a first network device for SRB configuration according to one or more embodiments of the present disclosure. The first network device may establish a signaling radio bearer (SRB) with the first UE to receive a RRC signaling message on the SRB. The first network device may set an SRB configuration for the SRB. The first network device may receive the RRC signaling message on the SRB with the SRB configuration from the first UE.

According to a third aspect of the disclosure there is provided a communication device in a communication network. The communication device may comprise a processor and a memory communicatively coupled to the processor. The memory may be adapted to store instructions which, when executed by the processor, cause the communication device to perform steps of the method according to the above first aspect, second aspect and third aspect.

According to a fourth aspect of the present disclosure, there is provided a non-transitory machine-readable medium having a computer program stored thereon. The computer program, when executed by a set of one or more processors of a communication device, causes the communication device to perform steps of the method according to the above first aspect, second aspect and third aspect.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure may be best understood by way of example with reference to the following description and accompanying drawings that are used to illustrate embodiments of the present disclosure.

Figure 1 shows a schematic diagram of multipath scenario in a communication network.

Figure 2 illustrates control plane protocol stacks using a Layer-2 UE- to-UE Relay according to the disclosure.

Figure 3 illustrates the protocol stack for the user plane transport according to the disclosure Figure 4 illustrates the protocol stack of the NAS connection for the Remote UE to the NAS-MM and NAS-SM components according to the disclosure.

Figure 5 illustrates the protocol stack for multipath according to the disclosure.

Figure 6 shows a diagram of direct path and indirect path in a communication network according to the disclosure.

Figure 7 illustrates an exemplary flow diagram for a method implemented by a first UE for SRB configuration according to one or more embodiments of the present disclosure.

Figure 8 illustrates an exemplary flow diagram for a method implemented by a first network device for SRB configuration according to one or more embodiments of the present disclosure.

Figure 9 is a block diagram illustrating a communication device according to some embodiments of the present disclosure.

Figure 10 is a block diagram of a communication system includes a telecommunication network 3210, in accordance with an embodiment of the present disclosure.

Figure 11 illustrates example implementations of the UE, base station and host computer in accordance with an embodiment of the present disclosure.

Figure 12 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment of the present disclosure.

Figure 13 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment of the present disclosure.

Figure 14 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment of the present disclosure.

Figure 15 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment of the present disclosure.

DETAILED DESCRIPTION

The following detailed description describes methods and apparatuses for binding indication. In the following detailed description, numerous specific details such as logic implementations, types and interrelationships of system components, etc. are set forth in order to provide a more thorough understanding of the present disclosure. It should be appreciated, however, by one skilled in the art that the present disclosure may be practiced without such specific details. In other instances, control structures, circuits and instruction sequences have not been shown in detail in order not to obscure the present disclosure. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

As used herein, the terms “first”, “second” and so forth refer to different elements. The singular forms “a”, “an”, and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms “comprises”, “comprising”, “has”, “having”, “includes” and/or “including” as used herein, specify the presence of stated features, elements, and/or components and the like, but do not preclude the presence or addition of one or more other features, elements, components and/or combinations thereof. The term “according to” is to be read as “at least in part according to”. The term “one embodiment” and “an embodiment” are to be read as “at least one embodiment”. The term “another embodiment” is to be read as “at least one other embodiment”.

Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meanings as commonly understood. It will be further understood that a term used herein should be interpreted as having a meaning consistent with its meaning in the context of this specification and the relevant art and will not be interpreted in an idealized or overly formal sense unless expressly so defined herein.

Bracketed text and blocks with dashed borders (e. g. , large dashes, small dashes, dot-dash, and dots) may be used herein to illustrate optional operations that add additional features to embodiments of the present disclosure. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments of the present disclosure.

An electronic device stores and transmits (internally and/or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine-readable media (also called computer-readable media), such as machine-readable storage media (e.g., magnetic disks, optical disks, read only memory (ROM), flash memory devices, phase change memory) and machine-readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals - such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors coupled to one or more machine-readable storage media to store code for execution on the set of processors and/or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code/ data even when the electronic device is turned off (when power is removed), and while the electronic device is turned on, that part of the code that is to be executed by the processor(s) of that electronic device is typically copied from the slower non-volatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of that electronic device. Typical electronic devices also include a set of or one or more physical network interfaces to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices. One or more parts of an embodiment of the present disclosure may be implemented using different combinations of software, firmware, and/or hardware.

In this disclosure a term node is used which can be a network node or a UE. Examples of network nodes are NodeB, base station (BS), multistandard radio (MSR) radio node such as MSR BS, eNodeB, gNodeB. MeNB, SeNB, integrated access backhaul (IAB) node, network controller, radio network controller (RNC), base station controller (BSC), relay, donor node controlling relay, base transceiver station (BTS), Central Unit (e.g. in a gNB), Distributed Unit (e.g. in a gNB), Baseband Unit, Centralized Baseband, C-RAN, access point (AP), transmission points, transmission nodes, RRU, RRH, nodes in distributed antenna system (DAS), core network node (e.g. MSC, MME etc), O&M, OSS, SON, positioning node (e.g. E-SMLC),etc.

Another example of a node is user equipment (UE), which is a nonlimiting term and refers to any type of wireless device communicating with a network node and/or with another UE in a cellular or mobile communication system. Examples of UE are target device, device to device (D2D) UE, vehicular to vehicular (V2V), machine type UE, MTC UE or UE capable of machine to machine (M2M) communication, PDA, Tablet, mobile terminals, smart phone, laptop embedded equipment (LEE), laptop mounted equipment (LME), USB dongles etc.

In some embodiments, generic terminology, “radio network node” or simply “network node (NW node)”, is used. It can be any kind of network node which may comprise base station, radio base station, base transceiver station, base station controller, network controller, evolved Node B (eNB), Node B, gNodeB (gNB), relay node, access point, radio access point, Remote Radio Unit (RRU) Remote Radio Head (RRH), Central Unit (e.g. in a gNB), Distributed Unit (e.g. in a gNB), Baseband Unit, Centralized Baseband, C-RAN, access point (AP etc.

The term radio access technology, or RAT, may refer to any RAT e.g. UTRA, E-UTRA, narrow band internet of things (NB-IoT), WiFi, Bluetooth, next generation RAT, New Radio (NR), 4G, 5G, etc. Any of the equipment denoted by the terminology node, network node or radio network node may be capable of supporting a single or multiple RATs.

Further, we use the term “direct path” to stand for a direct connection from a remote UE to a gNB (e.g., via NR air interface) and we use the term “indirect path” to stand for an indirect connection between a remote UE and a gNB via an intermediate node also known as relay UE. In the below embodiments, we assume an indirect path contains two hops i.e., PC5 hop between remote UE and relay UE, and Uu hop between relay UE and gNB. however, the embodiments are not limited to two hops. For an indirect path containing more than two hops, the embodiments are also applicable.

The embodiments are applicable to L2 relay scenarios.

In the embodiments, the UE (e.g., UE1) can connect to the same gNB (e.g., gNBl) via both a direct path (i.e., UE1 connects to the gNB via the Uu link directly in cell 1) and an indirect path (e.g., UE1 also connects to gNBl via a relay UE, i.e., UE2 in cell 2). Cell 1 and cell 2 may be the same or different. The Uu connection between UE1/UE2 and gNBl may be LTE Uu or NR Uu. The connection between UE1 and UE2 is also not limited to sidelink. Any short-range communication technology such as Wifi is equally applicable.

In the embodiments, one of the paths is defined as the primary path on which the UE transmits and/receive control plain signaling (including RRC signaling and/or lower layer signaling, e.g., MAC CE or LI signaling). The rest paths are referred to as secondary paths. The UE may also transmit and/receive control plain signaling via secondary paths. The embodiments are not limited by any term. The other similar term including primary and/or secondary connection/connectivity, master cell group (MCG) and/or secondary cell group (SCG), master and/or secondary connection/connectivity are interchangeably applicable.

The embodiments are also applicable to the case where UE1 connects to different gNBs via two different paths, wherein either of both paths can be a direct path or an indirect path.

The embodiments are also applicable to the case where UE1 connects to different gNBs via more than two paths, wherein any one of the paths can be a direct path or an indirect path.

In the below embodiments, a split SRB is configured for the remote UE where the first path is a direct path over Uu from the remote UE to the gNB and the second path is an indirect link using SL/PC5 from the remote UE to a relay UE and Uu from the relay UE to the gNB. In each of these paths, separate RLC entities are configured for the remote UE, a first RLC entity for the direct path and a second RLC entity for the indirect path.

SL physical channels

In NR sidelink, the following physical layer (PHY) channels are defined:

• PSCCH (Physical Sidelink Common Control Channel): This channel carries sidelink control information (SCI) including part of the scheduling assignment (SA) that allows a receiver to further process and decode the corresponding PSSCH (e.g., demodulation reference signal (DMRS) pattern and antenna port, MCS, etc). In addition, the PSCCH indicates future reserved resources. This allows a RX to sense and predict the utilization of the channel in the future. This sensing information is used for the purpose of UE-autonomous resource allocation (Mode 2), which is described below.

• PSSCH (Physical Sidelink Shared Channel): The PSSCH is transmitted by a sidelink transmitter UE, which conveys sidelink transmission data (i.e., the SL shared channel SL-SCH), and a part of the sidelink control information (SCI). In addition, higher layer control information may be carried using the PSSCH (e.g., MAC CEs, RRC signaling, etc.). For example, channel state information (CSI) is carried in the medium access control (MAC) control element (CE) over the PSSCH instead of the PSFCH. • PSFCH (Physical Sidelink feedback channel): The PSFCH is transmitted by a sidelink receiver UE for unicast and groupcast. It conveys the SL HARQ acknowledgement, which may consist of ACK/NACK (used for unicast and groupcast option 2) or NACK-only (used for groupcast option 1).

• Physical Sidelink Broadcast Channel (PSBCH): The PSBCH conveys information related to synchronization, such as the direct frame number (DFN), indication of the slot and symbol level time resources for sidelink transmissions, in-coverage indicator, etc. The SSB is transmitted periodically at every 160 ms. The PSBCH is transmitted along with the S- PSS/S-SSS as a sidelink synchronization signal block (S-SSB). o Sidelink Primary/Secondary Synchronization Signal (S-PSS/S-SSS) are used by UEs to establish a common timing references among UEs in the absence of another reference such as GNSS time of NW time.

Along with the different physical channels, reference signals (RS) are transmitted for different purposes, including demodulation (DM-RS), phase tracking RS (PT-RS), or RS for channel state information acquisition (CSI- RS).

Another new feature is the two-stage sidelink control information (SCI). A first part (first stage) of the SCI is sent on the PSCCH. This part is used for channel sensing purposes (including the reserved time-frequency resources for transmissions, demodulation reference signal (DMRS) pattern and antenna port, etc.) and can be read by all UEs while the remaining part (second stage) of the SCI carries the remaining scheduling and control information such as a 8-bits source identity (ID) and a 16-bits destination ID, NDI, RV and HARQ process ID is sent on the PSSCH to be decoded by the receiver UE.

Resource allocation

NR sidelink supports the following two modes of resource allocation:

• Mode 1: Sidelink resources are scheduled by a gNB. • Mode 2: The UE autonomously selects sidelink resources from a (pre-)configured sidelink resource pool. To avoid collisions between UEs a procedure based on the channel sensing and resource reservation is used.

An in-coverage UE can be configured by a gNB to use Mode 1 or Mode 2. For the out-of-coverage UE, only Mode 2 can be used.

Like in LTE, scheduling over the sidelink in NR is done in different ways for Mode 1 and Mode 2.

In Mode 1, the grant is provided by the gNB. The following two kinds of grants are supported:

• Dynamic grants are provided for one or multiple transmissions of a single packet (i.e., transport block). When the traffic to be sent over sidelink arrives at a transmitter UE (i.e., at the corresponding TX buffer), the UE initiates the four-message exchange procedure to request sidelink resources from a gNB (SR on UL, grant, BSR on UL, grant for data on SL sent to UE). A gNB indicates the resource allocation for the PSCCH and the PSSCH in the downlink control information (DCI) conveyed by PDCCH with CRC scrambled with the SL-RNTI of the corresponding UE. A UE receiving such a DCI, assumes that it has been provided a SL dynamic grant only if the detects that the CRC of DCI has been scrambled with its SL-RNTI. A transmitter UE then indicates the time-frequency resources and the transmission scheme of the allocated PSSCH in the PSCCH, and launches the PSCCH and the PSSCH on the allocated resources for sidelink transmissions. When a grant is obtained from a gNB, a transmitter UE can only transmit a single TB. As a result, this kind of grant is suitable for traffic with a loose latency requirement.

• Configured grant: For the traffic with a strict latency requirement, performing the four-message exchange procedure to request sidelink resources may induce unacceptable latency. In this case, prior to the traffic arrival, a transmitter UE may perform the four-message exchange procedure and request a set of resources. If a grant can be obtained from a gNB, then the requested resources are reserved in a periodic manner. Upon traffic arriving at a transmitter UE, this UE can launch the PSCCH and the PSSCH on the upcoming resource occasion. This kind of grant is also known as grant-free transmissions.

Note that only the transmitter UE is scheduled by the gNB. The receiver UE does not receive any information directly from the gNB. Instead, it is scheduled by the transmitter UE by means of the SCI. Therefore, a receiver UE should perform blind decoding to identify the presence of PSCCH and find the resources for the PSSCH through the SCI.

In Mode 2 resource allocation, the grant is generated by the UE itself. When traffic arrives at a transmitter UE (i.e., at the corresponding TX buffer), this transmitter autonomously selects resources for the PSCCH and the PSSCH. To further enhance the probability of successful TB decoding at one shot and thus suppress the probability to perform retransmissions, a transmitter UE may repeat the TB transmission along with the initial TB transmission. These retransmissions may be triggered by the corresponding SL HARQ feedback or may be sent blindly by the transmitter UE. In either case, to minimize the probability of collision for potential retransmissions, the transmitter UE may also reserve the corresponding resources for PSCCH/PSSCH for retransmissions. That is, the transmitter UE selects resources for:

1) The PSCCH/PSSCH corresponding to the first transmission.

2) The PSCCH/PSCCH corresponding to the retransmissions. Resources for up to 2 retransmissions may be reserved. These reserved resources are always used in case of blind retransmissions. If SL HARQ feedback is used, the used of the reserved resources is conditional on a negative SL HARQ acknowledgement.

Since each transmitter UE in sidelink transmissions should autonomously select resources for its own transmissions, preventing the different transmitter UEs from selecting the same resources turns out to be a critical issue in Mode 2. A particular resource selection procedure is therefore imposed to Mode 2 based on channel sensing. The channel sensing algorithm involves detecting the reservations transmitted by other UEs and performing power measurements (i.e., reference signal received power or RSRP) on the incoming transmissions.

Layer 2 UE-to-UE Relay

Figure 2 illustrates control plane protocol stacks using a Layer-2 UE- to-UE Relay according to the disclosure. The security is established end-to- end between UE1 and UE2 as shown by the Packet Data Convergence Protocol (PDCP) layer terminating in UE1 and UE2. Therefore, the E2E PC5-S message between UE1 and UE2 is never exposed at the relay node since the relay function does not process/apply any security on the relayed E2E PC5-S messages.

NOTE 1: The definition and functionalities of the Adaptation Layer are defined by RAN WG2.

NOTE 2: Only the End-to-End control plane protocol stack is shown in Figure 2. The control plane protocol stack of the unicast link between UE1/UE2 and UE-to-UE Relay (i.e. PC5 unicast link) can re-use the regular PC5-S protocol stack defined in clause 6.1.2 of TS 23.304 v 17.2.1.

NOTE 3: PC5-S messages from direct PC5 unicast link with the UE- to-UE Relay and for E2E PC5 unicast link are supported. The E2E PC5-S message is the message transferred between UE1 and UE2, and the direct PC5-S message is the message transferred between UE1 and UE-to-UE Relay or between UE-to-UE Relay and UE2. How to differentiate them depends on RAN solution. Whether the same pair of source and destination Layer-2 IDs is used for direct and E2E PC5-S messages is to be determine during SA WG2's normative phase and it's feasibility is to be confirmed by

- 14 -

RECTIFIED SHEET (RULE 91) ISA/EP RAN WG2.

1.1.1 ayer 2 UE-to-Network relay

In TR 23.752 [2], the layer-2 (L2) based UE-to-Network (U2N) relay is described.

Figure 3 illustrates the protocol stack for the user plane transport according to the disclosure, related to a Protocol Data Unit (PDU) Session, including a Layer 2 UE-to-Network Relay UE. The PDU layer corresponds to the PDU carried between the Remote UE and the Data Network (DN) over the PDU session. The PDU layer corresponds to the PDU carried between the Remote UE and the Data Network (DN) over the PDU session. It is important to note that the two endpoints of the PDCP link are the Remote UE and the gNB. The relay function is performed below PDCP. This means that data security is ensured between the Remote UE and the gNB without exposing raw data at the UE-to-Network Relay UE.

The adaptation layer within the UE-to-Network Relay UE can differentiate between signaling radio bearers (SRBs) and data radio bearers (DRBs) for a particular Remote UE. The adaption relay layer is also responsible for mapping PC5 traffic to one or more DRBs of the Uu.

Figure 4 illustrates the protocol stack of the Non Access Stratum (NAS) connection for the Remote UE to the NAS-MM and NAS-SM components according to the disclosure. The NAS messages are transparently transferred between the Remote UE and 5G-AN over the Layer 2 UE-to-Network Relay UE. The role of the UE-to-Network Relay UE is to relay the PDUs from the signaling radio bearer without any modifications.

In case a UE is configured with multipath, the protocol stack would be as in Figure 5. Figure 5 illustrates the protocol stack for multipath according to the disclosure. The data would be split at the PDCP layer and a PDCP PDU is submitted to either the Uu leg or the PC5 leg unless PDCP duplication is configured, in which case the PDCP PDU is submitted to both legs. Signalling radio bearers (SRBs)

The following excerpt from 3gpp TS 38.331 describes SRBs:

"Signalling Radio Bearers" (SRBs) are defined as Radio Bearers (RBs) that are used only for the transmission of RRC and NAS messages. More specifically, the following SRBs are defined:

- SRBO is for RRC messages using the Common Control Channel (CCCH) logical channel;

- SRB1 is for RRC messages (which may include a piggybacked NAS message) as well as for NAS messages prior to the establishment of SRB2, all using Dedicated Control Channel (DCCH) logical channel;

- SRB2 is for NAS messages and for RRC messages which include logged measurement information, all using DCCH logical channel. SRB2 has a lower priority than SRB 1 and may be configured by the network after AS security activation;

- SRB3 is for specific RRC messages when UE is in (NG)EN-DC or NR-DC, all using DCCH logical channel;

- SRB4 is for RRC messages which include application layer measurement report information, all using DCCH logical channel. SRB4 can only be configured by the network after AS security activation.

In downlink, piggybacking of NAS messages is used only for one dependant (i.e. with joint success/failure) procedure: bearer establishment/modification/release. In uplink piggybacking of NAS message is used only for transferring the initial NAS message during connection setup and connection resume.

NOTE 1: The NAS messages transferred via SRB2 are also contained in RRC messages, which however do not include any RRC protocol control information.

Once AS security is activated, all RRC messages on SRB1, SRB2, SRB3 and SRB4, including those containing NAS messages, are integrity protected and ciphered by PDCP. NAS independently applies integrity protection and ciphering to the NAS messages, see TS 24.501 [23],

Split SRB is supported for all the MR-DC options in both SRB 1 and SRB2 (split SRB is not supported for SRBO and SRB3).

For operation with shared spectrum channel access, SRBO, SRB1 and SRB3 are assigned with the highest priority Channel Access Priority Class (CAPC), (i.e. CAPC = 1) while CAPC for SRB2 is configurable.

Split RB

DRB split can be performed by the PDCP layer when more than one RLC entity is configured for the DRB. This is the case for e.g. dual connectivity where the UE is connected to two different cells. When a split DRB is configured, it is also possible to send the PDCP PDU using one of the legs. In legacy, the control of which path to use is based on the amount of data that is buffered for transmission so that when the buffer level is above a threshold, either of the paths may be used. It is also possible to configure PDCP duplication where the PDCP PDU is submitted to both legs. In TS 38.323 PDCP operation for split DRB and PDCP duplication is as follows:

When submitting a PDCP PDU to lower layer, the transmitting PDCP entity shall:

- if the transmitting PDCP entity is associated with one RLC entity:

- submit the PDCP PDU to the associated RLC entity;

- else, if the transmitting PDCP entity is associated with at least two RLC entities:

- if the PDCP duplication is activated for the RB:

- if the PDCP PDU is a PDCP Data PDU:

- duplicate the PDCP Data PDU and submit the PDCP Data PDU to the associated RLC entities activated for PDCP duplication;

- else:

- submit the PDCP Control PDU to the primary RLC entity;

- else (i.e. the PDCP duplication is deactivated for the RB or the RB is a DAPS bearer):

- if the split secondary RLC entity is configured; and

- if the total amount of PDCP data volume and RLC data volume pending for initial transmission (as specified in TS 38.322) in the primary RLC entity and the split secondary RLC entity is equal to or larger than ul- DataSplitThreshold'.

- submit the PDCP PDU to either the primary RLC entity or the split secondary RLC entity;

- else, if the transmitting PDCP entity is associated with the DAPS bearer:

- if the uplink data switching has not been requested:

- submit the PDCP PDU to the RLC entity associated with the source cell;

- else:

- if the PDCP PDU is a PDCP Data PDU:

- submit the PDCP Data PDU to the RLC entity associated with the target cell;

- else:

- if the PDCP Control PDU is associated with source cell:

- submit the PDCP Control PDU to the RLC entity associated with the source cell;

- else:

- submit the PDCP Control PDU to the RLC entity associated with the target cell;

- else:

- submit the PDCP PDU to the primary RLC entity.

NOTE 2: If the transmitting PDCP entity is associated with two RLC entities, the UE should minimize the amount of PDCP PDUs submitted to lower layers before receiving request from lower layers and minimize the PDCP SN gap between PDCP PDUs submitted to two associated RLC entities to minimize PDCP reordering delay in the receiving PDCP entity.

In 3GPP Rel.18, specification of multipath for SL will be done. This may enable the use of split DRBs, meaning that the data can be sent over either of the paths to gNB, either the direct path over UU or the indirect path using relaying via a relay UE. It may also be possible to configure PDCP duplication for DRBs, which will increase reliability and reduce latency.

When multipath is configured, it could also be possible to configure split SRBs. In this case the SRB could be configured to use either of the paths to gNB. Since the reliability and latency of SRB transmissions is important it would also be useful to configure SRB duplication.

In legacy, the buffer status is used to control path selection for split DRBs. However, buffer status is not a useful control mechanism for split SRBs. In this disclosure, different methods are defined to control split SRBs and SRB duplication.

Therefore, it is necessary to study the above issues and develop corresponding solutions.

The present disclosure proposes mechanisms for the configuration of split SRBs and activation of SRB duplication for SL multi-connectivity. In one embodiment, the path is selected or SRB duplication is activated based on radio-link quality defined by for example RSRP, latency, and bitrate. The path selection can also be combined with buffer status of the respective paths. The type of RRC message or SRB type may also be taken into account in the selection process.

With solutions proposed in this disclosure, the use of split SRB is designed to enable reliable and low latency delivery of RRC messages transmitted using SRB1, SRB2 and SRB4.

In an embodiment, whenever UE1 has a RRC signaling message to transmit on an SRB, the selection of path for submission of the PDCP PDUs containing the RRC signaling for the SRB is done for the remote UE using one of the following options or combinations thereof: • Option 1: select the path according to a configuration. o The configuration may be signalled by gNBl via signaling alternatives including RRC signaling, MAC CE, or L 1 signaling. o The configuration is preconfigured to UE1. o UE1 may provide measurement results in terms of metrics including radio channel quality (e.g., RSRP, RSRQ, RS SI, SINR, SIR etc), channel congestion (e.g., channel occupancy, channel busy ratio etc), HARQ statistics (e.g., HARQ NACK ratio) etc to gNB 1 , based on which gNB 1 can determine which path to use for transmission signaling of a specific type of SRB o UE1 may indicate a preferred path for a specific type of SRB to gNBl. Based on which, gNBl can determine which path to use for transmission signaling of the specific type of SRB

• Option 2: select the direct path if the RSRP on the Uu link (RSRPuu) is higher than a threshold (THr RSRPuu), i.e. if RSRPuu > THr RSRPuu , choose the direct path else choose the indirect path.

Alternatively, a separate RSRP threshold is defined for the PC5 hop of the indirect path, only when the measured radio quality of the PC5 hop is higher than the threshold, UE1 selects the indirect path.

• Option 3: select the direct path if the buffered data at a certain layer (e.g., RLC layer) on the direct path (RLC entity 1) is less than a configurable threshold, else if the buffered data at a certain layer ( e.g., RLC layer) on the direct path (RLC entity 1) is larger than the configurable threshold, select the indirect path o When the buffer data is equal to the configurable threshold, UE1 may choose the direct path. Alternatively, UE1 may choose the indirect path

• Option 4: select the direct path for the PDCP PDU containing the SRB data if the data comes from a specific SRB type, i.e. SRB1, SRB2 or SRB4. o In one option, the determination is based on the size of the SRB data.

• Option 5: select the path according to measured latency of previously delivered signaling and/or data message on each path. o If the measured latency on the current path is above a threshold, UE1 selects another path which is able to give lower latency o UE1 selects the path which gives shortest latency among all paths o In one option, the determination is based on the time required to obtain an indication of that a previously transmitted PDCP PDU has been delivered or a previously transmitted/buffered PDCP/RLC PDU has been discarded or a RLC acknowledgement or a HARQ acknowledgement. o UE1 may inform the measured latency on the current path to the gNB, based on which the gNB may determine to select another path to deliver the PDCP PDU of UEl’s SRB and inform the determination to UE1. o The relay UE may informs the remote UE that PDCP PDU of a certain SRB received from the remote UE has stayed in relay UE’s Tx buffer more than a certain time, which triggers the remote UE to deliver the PDCP PDU of the SRB to another path, o The relay UE may inform the gNB that PDCP PDU of a certain SRB of a remote UE received from the gNB has stayed in relay UE’s Tx buffer more than a certain time, and the gNB may deliver the PDCP PDU of the SRB of the remote UE to another path.

• Option 6: select the direct path if the Uu and/or PC5 traffic load at the relay UE exceeds a certain threshold.

Note For any one of the above options in the first embodiment, UE1 may apply different options for different SRB types, given that different SRBs may give signaling messages of different sizes and different priority levels.

In another embodiment, activation of PDCP duplication for SRB, i.e. submitting the same PDCP PDU for an SRB is done to more than two paths by the remote UE using one of the following options or combinations thereof:

• Option 1: PDCP duplication is activated for PDCP PDU containing the SRB data if the RSRP on the Uu link (RSRPuu) is less than a configurable threshold (THr RSRPuu), i.e. if RSRPuu < THr RSRPuu . o In one option, the RSRP on the SL (RSRPSL ) is also taken into account, e.g if RSRPuu < THr RSRPuu and RSRPSL < THr RSRPsL, then PDCP duplication is activated for PDCP PDU containing the SRB data

• Option 2: PDCP duplication is activated for PDCP PDU containing the SRB data if the number of buffered RLC SDUs containing the SRB data or other data in the first RLC entity is larger than a configurable threshold which implies the SRB data or other data has been in the first RLC buffer for a certain time,

• Option 3: PDCP duplication is activated for PDCP PDU containing the SRB data or other data if the total number of buffered SRB data or other data at certain protocol layer (e.g., PDCP) is larger than a configurable threshold which implies the SRB data has been in the buffer at certain protocol layer for a certain time.

• Option 4: PDCP duplication is activated for PDCP PDU containing the SRB data if the data comes from a specific SRB type, i.e. SRB1, SRB2 or SRB4. o In one option, the determination is based on the size of the SRB data.

• Option 5: PDCP duplication is activated for PDCP PDU containing the SRB data if the latency of previously delivered PDCP PDUs on a single path is above a configurable threshold. o In one option, the determination is based on the time required to obtain an indication of that a previously transmitted PDCP PDU has been delivered or a previously transmitted/buffered PDCP/RLC PDU has been discarded or a RLC acknowledgement or a HARQ acknowledgement. o UE1 may inform the (shortest) measured latency at RLC layer over all the paths being used to deliver a SRB to the gNB, based on which the gNB may determine whether or not to activate duplication, i.e., whether or not to deliver the PDCP PDU of the SRB over multiple paths and inform the determination to UE1. o The relay UE may inform the remote UE that PDCP PDU of a certain SRB received from the remote UE has stayed in relay UE’s Tx buffer more/less than a certain time, which may trigger the remote UE to activte/deactivate duplication, i.e., deliver the PDCP PDU of the SRB to multiple paths or only the path via the relay UE. o The relay UE may inform the gNB that PDCP PDU of a certain SRB of a remote UE received from the gNB has stayed in relay UE’s Tx buffer more/less than a certain time, based on which the gNB may activte/deactivate duplication, i.e., deliver the PDCP PDU of the SRB to multiple paths or only the path via the relay UE and inform the determination to the remote UE.

Note

• For any one of the above options in the second embodiment, UE1 may apply different options for different SRB types, given that different SRBs may give signaling messages of different sizes and different priority levels o E.g., one SRB may enable PDCP duplication, while another SRB may disable PDCP duplication.

As an additional embodiment, additional UE capabilities for indicating either of the following may be introduced

• Indicating whether UE supports split SRB

• Indicating whether UE support PDCP duplication for SRB

As an additional embodiment, selection of path for transmitting SRB and/or activation of PDCP duplication for SRB are configured/performed separately in UL and DL, e.g., a SRB may be transmitted in one path in UL while in a different path in DL, PDCP duplication may be activated for a SRB only in UL or only in DL or both.

As an additional embodiment, for any of the above embodiments, any signaling exchanged between UE and the gNB via Uu interface can be transmitted via at least one of the following alternatives:

- RRC signaling

- MAC CE

- Paging message

- Control PDU of a protocol layer (e.g., SDAP, PDCP, RLC, or an adaptation layer in case of SL relay)

- LI signaling on channels such as PRACH, PUCCH, PDCCH etc

Any signaling exchanged between UEs via the PC5 interface can be transmitted via at least one fo the following signaling alternatives:

- RRC signaling (e.g., PC5-RRC)

- PC5-S signaling

- Discovery signaling

- MAC CE

- Control PDU of a protocol layer (e.g., SDAP, PDCP, RLC, or an adaptation layer in case of SL relay)

LI signaling on channels such as PSSCH, PSCCH, or PSFCH etc.

Figure 6 shows a diagram of direct path and indirect path in a communication network according to one or more embodiments, we use the term “direct path” to stand for a direct connection from a remote UE to a gNB (e.g., via NR air interface) and we use the term “indirect path” to stand for an indirect connection between a remote UE and a gNB via an intermediate node also known as relay UE. In the below embodiments, we assume an indirect path contains two hops i.e., PC5 hop between remote UE and relay UE, and Uu hop between relay UE and gNB. however, the embodiments are not limited to two hops. For an indirect path containing more than two hops, the embodiments are also applicable.

The embodiments are applicable to L2 relay scenarios.

In the embodiments, the UE (e.g., UE1) can connect to the same gNB (e.g., gNBl) via both a direct path (i.e., UE1 connects to the gNB via the Uu link directly in cell 1) and an indirect path (e.g., UE1 also connects to gNBl via a relay UE, i.e., UE2 in cell 2). Cell 1 and cell 2 may be the same or different. The Uu connection between UE1/UE2 and gNBl may be LTE Uu or NR Uu. The connection between UE1 and UE2 is also not limited to sidelink. Any short-range communication technology such as Wifi is equally applicable.

In the embodiments, one of the paths is defined as the primary path on which the UE transmits and/receive control plain signaling (including RRC signaling and/or lower layer signaling, e.g., Media Access Control (MAC) Control Element (CE) or LI signaling). The rest paths are referred to as secondary paths. The UE may also transmit and/receive control plain signaling via secondary paths. The embodiments are not limited by any term. The other similar term including primary and/or secondary connection/connectivity, master cell group (MCG) and/or secondary cell group (SCG), master and/or secondary connection/connectivity are interchangeably applicable.

The embodiments are also applicable to the case where UE1 connects to different gNBs via two different paths, wherein either of both paths can be a direct path or an indirect path. The embodiments are also applicable to the case where UE1 connects to different gNBs via more than two paths, wherein any one of the paths can be a direct path or an indirect path.

In the below embodiments, a split SRB is configured for the remote UE where the first path is a direct path over Uu from the remote UE to the gNB and the second path is an indirect link using SL/PC5 from the remote UE to a relay UE and Uu from the relay UE to the gNB. In each of these paths, separate RLC entities are configured for the remote UE, a first RLC entity for the direct path and a second RLC entity for the indirect path.

Figure 7 illustrates an exemplary flow diagram 700 for a method implemented by a first UE for SRB configuration according to one or more embodiments of the present disclosure.

With reference to Figure 7, in step 701, the first UE may establish a signaling radio bearer (SRB) with the first network device to transmit a RRC signaling message on the SRB. In step 702, the first UE may set an SRB configuration for the SRB. In step 703, the first UE may transmit the RRC signaling message on the SRB using the SRB configuration to the first network device.

According to an embodiment, setting an SRB configuration for the SRB may include selecting one of the direct path or the indirect path for the SRB for submission of one or more PDCP PDUs containing the RRC signaling message.

According to an embodiment, setting an SRB configuration for the SRB may include activation of PDCP duplication for the SRB for submission one or more PDCP PDUs containing the RRC signaling message on both the direct path and the indirect path.

According to an embodiment, the first UE may further receive a configuration message from the first network device; and select the direct path or the indirect path for the SRB according to the configuration message.

According to an embodiment, the first UE may further select the direct path or the indirect path for the SRB according to the preconfiguration for the first UE.

According to an embodiment, the first UE may further provide measurement results to the first network device; receive a configuration message from the first network device indicating which one of the direct path or indirect path to use for transmission of a specific type of SRB; and select the direct path or indirect path for the SRB according to the configuration message.

According to an embodiment, the first UE may further send a path selection information indicating a preferred path for a specific type of SRB to the first network device; and receive a configuration message from the first network device indicating which one of the direct path or indirect path to use for transmission of the specific type of SRB; and select one of the direct path or indirect path for the SRB according to the configuration message.

According to an embodiment, the first UE may further select the direct path for the SRB, if the RSRP on the first link between the first UE and the first network device is higher than a first threshold; or else select the indirect path for the SRB.

According to an embodiment, the first UE may further select the indirect path for the SRB, if the RSRP on the second link between the first UE and the second UE is higher than a second threshold.

According to an embodiment, the first UE may further select the direct path for the SRB, if the buffered data at a certain layer on the direct path is less than a third threshold; or else if the buffered data at a certain layer on the direct path is larger than the third threshold, the first UE may select the indirect path for the SRB; or the first UE may select the direct path or indirect path for the SRB, if the buffered data at a certain layer on the direct path is equal to the third threshold.

According to an embodiment, the first UE may further select the direct path for the SRB, if the SRB is of a specific SRB type.

According to an embodiment, wherein the specific SRB type includes, SRB1, SRB2, or SRB4.

According to an embodiment, the first UE may further select one of the direct path or the indirect path for the SRB based on the size of SRB data contained in the one or more PCDP PDUs.

According to an embodiment, the first UE may further select one of the direct path or the indirect path for the SRB according to measured latency of previously delivered signaling or data message on the direct path and the indirect path.

According to an embodiment, if the measured latency on one of the direct path or the indirect path for the SRB is above a fourth threshold, the first UE may further select the other one of the direct path or the indirect path.

According to an embodiment, the first UE may further select one of the direct path or the indirect path with the shortest latency among all paths.

According to an embodiment, the measured latency includes the time required to obtain an indication of that a previously transmitted PDCP PDU has been delivered or a previously transmitted PDCP/Radio Link Control (RLC)PDU has been discarded or a RLC acknowledgement or a HARQ acknowledgement.

According to an embodiment, the first UE may further send the measured latency on one of the direct path or the indirect path to the first network device; and receive a configuration message from the first network device, indicating selection of the other one of the direct path or the indirect path for the SRB.

According to an embodiment, the first UE may further receive a path selection trigger from the second UE indicating that PDCP PDU of a SRB received from the first UE on one of the direct path or the indirect path has stayed in the second UE’s Tx buffer more than a certain time period; and select the other one of the direct path or the indirect path for the SRB.

According to an embodiment, the first UE may further receive a traffic load information from the second UE, including a Uu or PC5 traffic load of the second UE; and select the direct path for the SRB, if the Uu or PC5 traffic load exceeds a fifth threshold.

According to an embodiment, the first UE may further activate PDCP duplication for the SRB, if the RSRP on the first link between the first UE and the first network device is less than a sixth threshold.

According to an embodiment, the first UE may further activate PDCP duplication for the SRB, if the RSRP on the first link between the first UE and the first network device is less than a sixth threshold and the RSRP on the second link between the first UE and the second UE is less than a seventh threshold.

According to an embodiment, the first UE may further activate PDCP duplication for the SRB, if the number of buffered RLC SDUs for the SRB in the RLC entity of the first UE is larger than an eighth threshold.

According to an embodiment, the first UE may further activate PDCP duplication for the SRB, if the total number of buffered SRB data for the SRB at certain protocol layer is larger than a ninth threshold.

According to an embodiment, the first UE may further activate PDCP duplication for the SRB, if the SRB is of a specific SRB type.

According to an embodiment, the first UE may further activate PDCP duplication for the SRB, if the measured latency of previously delivered PDCP PDUs for the SRB on one of the direct path or the indirect path is above a tenth threshold.

According to an embodiment, the measured latency includes the time required to obtain an indication of that a previously transmitted PDCP PDU has been delivered or a previously transmitted PDCP/RLC PDU has been discarded or a RLC acknowledgement or a HARQ acknowledgement.

According to an embodiment, the first UE may further send the measured latency on each one of the direct path or the indirect path to the first network device; and receive a configuration message from the first network device, indicating whether to activate PDCP duplication for the SRB. According to an embodiment, the first UE may further receive a PDCP duplication activation trigger from the second UE indicating that PDCP PDU of a certain SRB received from the first UE has stayed in the second UE’s Tx buffer is more than or less than a certain time period; and activate or deactivate PDCP duplication for the SRB.

According to an embodiment, the first UE may have UE capability for indicating whether the first UE supports split SRB or whether the first UE supports PDCP duplication for SRB.

According to an embodiment, the SRB configuration may be set separately on uplink and downlink.

Figure 8 illustrates an exemplary flow diagram 800 for a method implemented by a first network device for SRB configuration according to one or more embodiments of the present disclosure.

With reference to Figure 8, in step 801, the first network device may establish a signaling radio bearer (SRB) with the first UE to receive a RRC signaling message on the SRB. In step 802, the first network device may set an SRB configuration for the SRB. In step 803, the first network device may receive the RRC signaling message on the SRB with the SRB configuration from the first UE.

According to an embodiment, setting an SRB configuration for the SRB may include selecting one of the direct path or the indirect path for the SRB for submission of one or more PDCP PDUs containing the RRC signaling message.

According to an embodiment, setting an SRB configuration for the SRB includes activation of PDCP duplication for the SRB for submission of one or more PDCP PDUs containing the RRC signaling message on the direct path and the indirect path both.

According to an embodiment, the first network device may further send a configuration message to the first UE to indicate which one of the direct path or the indirect path to use for the SRB.

According to an embodiment, the first network device may further receive measurement results from the first UE; select one of the direct path or the indirect path based on the measurement results; and send a configuration message to the first UE indicating which one of the direct path or indirect path to use for a specific type of SRB.

According to an embodiment, the first network device may further receive a path selection information indicating a preferred path for a specific type of SRB from the first UE; and send a configuration message to the first UE indicating which one of the direct path or indirect path to use for the specific type of SRB.

According to an embodiment, the first network device may further receive the measured latency on one of the direct path or the indirect path from the first UE; and send a configuration message to the first UE, indicating selection of the other one of the direct path or the indirect path for the SRB.

According to an embodiment, the first network device may further receive a path selection trigger from the second UE indicating that PDCP PDU of a SRB of the first UE received from the first network device on one of the direct path or the indirect path has stayed in the second UE’s Tx buffer more than a certain time period; and select the other one of the direct path or the indirect path for the SRB.

According to an embodiment, the first network device may further receive the measured latency on each one of the direct path or the indirect path from the first UE; and send a configuration message to the first UE, indicating whether to activate PDCP duplication for the SRB based on the measured latency.

According to an embodiment, the first network device may further receive a PDCP duplication activation trigger from the second UE indicating that PDCP PDU of a certain SRB of the first UE received from the first network device has stayed in the second UE’s Tx buffer is more than or less than a certain time period; and activate or deactivate PDCP duplication for the SRB. According to an embodiment, the SRB configuration is set separately on uplink and downlink.

Figure 9 is a block diagram illustrating a communication device 900 according to some embodiments of the present disclosure. It should be appreciated that the communication device 900 may be implemented using components other than those illustrated in Figure 9.

With reference to Figure 9, the communication device 900 may comprise at least a processor 901, a memory 902, an interface and a communication medium. The processor 901, the memory 902 and the interface are communicatively coupled to each other via the communication medium.

The processor 901 includes one or more processing units. A processing unit may be a physical device or article of manufacture comprising one or more integrated circuits that read data and instructions from computer readable media, such as the memory 902, and selectively execute the instructions. In various embodiments, the processor 901 is implemented in various ways. As an example, the processor 901 may be implemented as one or more processing cores. As another example, the processor 901 may comprise one or more separate microprocessors. In yet another example, the processor 901 may comprise an application-specific integrated circuit (ASIC) that provides specific functionality. In yet another example, the processor 901 provides specific functionality by using an ASIC and by executing computer-executable instructions.

The memory 902 includes one or more computer-usable or computer- readable storage medium capable of storing data and/or computerexecutable instructions. It should be appreciated that the storage medium is preferably a non-transitory storage medium.

The communication medium facilitates communication among the processor 901, the memory 902 and the interface. The communication medium may be implemented in various ways. For example, the communication medium may comprise a Peripheral Component Interconnect (PCI) bus, a PCI Express bus, an accelerated graphics port (AGP) bus, a serial Advanced Technology Attachment (ATA) interconnect, a parallel ATA interconnect, a Fiber Channel interconnect, a USB bus, a Small Computing System Interface (SCSI) interface, or another type of communications medium. The interface could be coupled to the processor. Information and data as described above in connection with the methods may be sent via the interface.

In the example of Figure 9, the instructions stored in the memory 902 may include those that, when executed by the processor 901 , cause the communication device 900 to implement the methods described with respect to Figs. 7-8.

With reference to Figure 10, in accordance with an embodiment, a communication system includes a telecommunication network 3210, such as a 3 GPP-type cellular network, which comprises an access network 3211, such as a radio access network, and a core network 3214. The access network 3211 comprises a plurality of base stations 3212a, 3212b, 3212c, such as NBs, eNBs, gNBs or other types of wireless access points, each defining a corresponding coverage area 3213a, 3213b, 3213c. Each base station 3212a, 3212b, 3212c is connectable to the core network 3214 over a wired or wireless connection 3215. A first UE 3291 located in coverage area 3213c is configured to wirelessly connect to, or be paged by, the corresponding base station 3212c. A second UE 3292 in coverage area 3213a is wirelessly connectable to the corresponding base station 3212a. While a plurality of UEs 3291, 3292 are illustrated in this example, the disclosed embodiments are equally applicable to a situation where a sole UE is in the coverage area or where a sole UE is connecting to the corresponding base station 3212.

The telecommunication network 3210 is itself connected to a host computer 3230, which may be embodied in the hardware and/or software of a standalone server, a cloud-implemented server, a distributed server or as processing resources in a server farm. The host computer 3230 may be under the ownership or control of a service provider, or may be operated by the service provider or on behalf of the service provider. The connections 3221, 3222 between the telecommunication network 3210 and the host computer 3230 may extend directly from the core network 3214 to the host computer 3230 or may go via an optional intermediate network 3220. The intermediate network 3220 may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network 3220, if any, may be a backbone network or the Internet; in particular, the intermediate network 3220 may comprise two or more sub-networks (not shown).

The communication system of Fig. 10 as a whole enables connectivity between one of the connected UEs 3291, 3292 and the host computer 3230. The connectivity may be described as an over-the-top (OTT) connection 3250. The host computer 3230 and the connected UEs 3291, 3292 are configured to communicate data and/or signaling via the OTT connection 3250, using the access network 3211, the core network 3214, any intermediate network 3220 and possible further infrastructure (not shown) as intermediaries. The OTT connection 3250 may be transparent in the sense that the participating communication devices through which the OTT connection 3250 passes are unaware of routing of uplink and downlink communications. For example, a base station 3212 may not or need not be informed about the past routing of an incoming downlink communication with data originating from a host computer 3230 to be forwarded (e.g., handed over) to a connected UE 3291. Similarly, the base station 3212 need not be aware of the future routing of an outgoing uplink communication originating from the UE 3291 towards the host computer 3230.

Example implementations, in accordance with an embodiment, of the UE, base station and host computer discussed in the preceding paragraphs will now be described with reference to Fig. 11. In a communication system 3300, a host computer 3310 comprises hardware 3315 including a communication interface 3316 configured to set up and maintain a wired or wireless connection with an interface of a different communication device of the communication system 3300. The host computer 3310 further comprises processing circuitry 3318, which may have storage and/or processing capabilities. In particular, the processing circuitry 3318 may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The host computer 3310 further comprises software 3311, which is stored in or accessible by the host computer 3310 and executable by the processing circuitry 3318. The software 3311 includes a host application 3312. The host application 3312 may be operable to provide a service to a remote user, such as a UE 3330 connecting via an OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the remote user, the host application 3312 may provide user data which is transmitted using the OTT connection 3350.

The communication system 3300 further includes a base station 3320 provided in a telecommunication system and comprising hardware 3325 enabling it to communicate with the host computer 3310 and with the UE 3330. The hardware 3325 may include a communication interface 3326 for setting up and maintaining a wired or wireless connection with an interface of a different communication device of the communication system 3300, as well as a radio interface 3327 for setting up and maintaining at least a wireless connection 3370 with a UE 3330 located in a coverage area (not shown in Fig. 11) served by the base station 3320. The communication interface 3326 may be configured to facilitate a connection 3360 to the host computer 3310. The connection 3360 may be direct or it may pass through a core network (not shown in Fig. 11) of the telecommunication system and/or through one or more intermediate networks outside the telecommunication system. In the embodiment shown, the hardware 3325 of the base station 3320 further includes processing circuitry 3328, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The base station 3320 further has software 3321 stored internally or accessible via an external connection.

The communication system 3300 further includes the UE 3330 already referred to. Its hardware 3335 may include a radio interface 3337 configured to set up and maintain a wireless connection 3370 with a base station serving a coverage area in which the UE 3330 is currently located. The hardware 3335 of the UE 3330 further includes processing circuitry 3338, which may comprise one or more programmable processors, application-specific integrated circuits, field programmable gate arrays or combinations of these (not shown) adapted to execute instructions. The UE 3330 further comprises software 3331, which is stored in or accessible by the UE 3330 and executable by the processing circuitry 3338. The software 3331 includes a client application 3332. The client application 3332 may be operable to provide a service to a human or non- human user via the UE 3330, with the support of the host computer 3310. In the host computer 3310, an executing host application 3312 may communicate with the executing client application 3332 via the OTT connection 3350 terminating at the UE 3330 and the host computer 3310. In providing the service to the user, the client application 3332 may receive request data from the host application 3312 and provide user data in response to the request data. The OTT connection 3350 may transfer both the request data and the user data. The client application 3332 may interact with the user to generate the user data that it provides.

It is noted that the host computer 3310, base station 3320 and UE 3330 illustrated in Fig. 11 may be identical to the host computer 3230, one of the base stations 3212a, 3212b, 3212c and one of the UEs 3291, 3292 of Fig. 11, respectively. This is to say, the inner workings of these entities may be as shown in Fig. 10 and independently, the surrounding network topology may be that of Fig. 10.

In Fig. 11, the OTT connection 3350 has been drawn abstractly to illustrate the communication between the host computer 3310 and the use equipment 3330 via the base station 3320, without explicit reference to any intermediary devices and the precise routing of messages via these devices. Network infrastructure may determine the routing, which it may be configured to hide from the UE 3330 or from the service provider operating the host computer 3310, or both. While the OTT connection 3350 is active, the network infrastructure may further take decisions by which it dynamically changes the routing (e.g., on the basis of load balancing consideration or reconfiguration of the network).

The wireless connection 3370 between the UE 3330 and the base station 3320 is in accordance with the teachings of the embodiments described throughout this disclosure One or more of the various embodiments improve the performance of OTT services provided to the UE

3330 using the OTT connection 3350, in which the wireless connection 3370 forms the last segment. More precisely, the teachings of these embodiments may improve the latency and power consumption and thereby provide benefits such as reduced user waiting time, better responsiveness, extended battery lifetime.

A measurement procedure may be provided for the purpose of monitoring data rate, latency, and other factors on which the one or more embodiments improve. There may further be an optional network functionality for reconfiguring the OTT connection 3350 between the host computer 3310 and UE 3330, in response to variations in the measurement results. The measurement procedure and/or the network functionality for reconfiguring the OTT connection 3350 may be implemented in the software 3311 of the host computer 3310 or in the software 3331 of the UE 3330, or both. In embodiments, sensors (not shown) may be deployed in or in association with communication devices through which the OTT connection 3350 passes; the sensors may participate in the measurement procedure by supplying values of the monitored quantities exemplified above, or supplying values of other physical quantities from which software 3311,

3331 may compute or estimate the monitored quantities. The reconfiguring of the OTT connection 3350 may include message format, retransmission settings, preferred routing etc.; the reconfiguring need not affect the base station 3320, and it may be unknown or imperceptible to the base station 3320. Such procedures and functionalities may be known and practiced in the art. In certain embodiments, measurements may involve proprietary UE signaling facilitating the host computer’s 3310 measurements of throughput, propagation times, latency, and the like. The measurements may be implemented in that the software 3311, 3331 causes messages to be transmitted, in particular empty or ‘dummy’ messages, using the OTT connection 3350 while it monitors propagation times, errors etc.

Fig. 12 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 10 and Fig. 11. For simplicity of the present disclosure, only drawing references to Fig. 11 will be included in this section. In a first step 3410 of the method, the host computer provides user data. In an optional substep 3411 of the first step 3410, the host computer provides the user data by executing a host application. In a second step 3420, the host computer initiates a transmission carrying the user data to the UE. In an optional third step 3430, the base station transmits to the UE the user data which was carried in the transmission that the host computer initiated, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional fourth step 3440, the UE executes a client application associated with the host application executed by the host computer.

Fig. 13 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 11 and Fig. 12. For simplicity of the present disclosure, only drawing references to Fig. 13 will be included in this section. In a first step 3510 of the method, the host computer provides user data. In an optional substep (not shown) the host computer provides the user data by executing a host application. In a second step 3520, the host computer initiates a transmission carrying the user data to the UE. The transmission may pass via the base station, in accordance with the teachings of the embodiments described throughout this disclosure. In an optional third step 3530, the UE receives the user data carried in the transmission.

Fig. 14 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 10 and Fig. 11. For simplicity of the present disclosure, only drawing references to Fig. 14 will be included in this section. In an optional first step 3610 of the method, the UE receives input data provided by the host computer. Additionally or alternatively, in an optional second step 3620, the UE provides user data. In an optional substep 3621 of the second step 3620, the UE provides the user data by executing a client application. In a further optional substep 3611 of the first step 3610, the UE executes a client application which provides the user data in reaction to the received input data provided by the host computer. In providing the user data, the executed client application may further consider user input received from the user. Regardless of the specific manner in which the user data was provided, the UE initiates, in an optional third substep 3630, transmission of the user data to the host computer. In a fourth step 3640 of the method, the host computer receives the user data transmitted from the UE, in accordance with the teachings of the embodiments described throughout this disclosure.

Fig. 15 is a flowchart illustrating a method implemented in a communication system, in accordance with one embodiment. The communication system includes a host computer, a base station and a UE which may be those described with reference to Fig. 10 and Fig. 11. For simplicity of the present disclosure, only drawing references to Fig. 15 will be included in this section. In an optional first step 3710 of the method, in accordance with the teachings of the embodiments described throughout this disclosure, the base station receives user data from the UE. In an optional second step 3720, the base station initiates transmission of the received user data to the host computer. In a third step 3730, the host computer receives the user data carried in the transmission initiated by the base station.