Patent Application
20210344467
Various example embodiments relates to wireless communications.
Factory floor presents a challenging radio propagation environment for ultra-reliable low latency communication (URLLC) often required for industrial automation scenarios. For example, the machinery in the factory may cause interference while bulky metallic structures and objects prevalent in many factories may cause blockage or at least significant attenuation. As a result of these effects, the signal detection rate may not be sufficient for URLLC unless steps are taken to over-come or alleviate at least some of the aforementioned problems.
According to an aspect, there is provided the subject matter of the independent claims. Embodiments are defined in the dependent claims.
One or more examples of implementations are set forth in more detail in the accompanying drawings and the description below. Other features will be apparent from the description and drawings, and from the claims.
In the following, example embodiments will be described in greater detail with reference to the attached drawings, in which
The following embodiments are only presented as examples. Although the specification may refer to “an”, “one”, or “some” embodiment(s) and/or example(s) in several locations of the text, this does not necessarily mean that each reference is made to the same embodiment(s) or example(s), or that a particular feature only applies to a single embodiment and/or example. Single features of different embodiments and/or examples may also be combined to provide other embodiments and/or examples.
Embodiments and examples described herein may be implemented in any communications system comprising wireless connection(s). In the following, different exemplifying embodiments will be described using, as an example of an access architecture to which the embodiments may be applied, a radio access architecture based on long term evolution advanced (LTE Advanced, LTE-A) or new radio (NR, 5G), without restricting the embodiments to such an architecture, however. It is obvious for a person skilled in the art that the embodiments may also be applied to other kinds of communications networks having suitable means by adjusting parameters and procedures appropriately. Some examples of other options for suitable systems are the universal mobile telecommunications system (UMTS) radio access network (UTRAN or E-UTRAN), long term evolution (LTE, the same as E-UTRA), beyond 5G, wireless local area network (WLAN or WiFi), worldwide interoperability for microwave access (WiMAX), Bluetooth®, personal communications services (PCS), ZigBee®, wideband code division multiple access (WCDMA), systems using ultra-wideband (UWB) technology, sensor networks, mobile ad-hoc networks (MANETs) and Internet Protocol multimedia subsystems (IMS) or any combination thereof.
The embodiments are not, however, restricted to the system given as an example but a person skilled in the art may apply the solution to other communication systems provided with necessary properties.
The example of
A communications system typically comprises more than one (e/g)NodeB in which case the (e/g)NodeBs may also be configured to communicate with one another over links, wired or wireless, designed for the purpose. These links may be used for signalling purposes. The (e/g)NodeB is a computing device configured to control the radio resources of communication system it is coupled to. The NodeB may also be referred to as a base station, an access point or any other type of interfacing device. The (e/g)NodeB includes or is coupled to transceivers. From the transceivers of the (e/g)NodeB, a connection is provided to an antenna unit that establishes bi-directional radio links to user devices. The antenna unit may comprise a plurality of antennas or antenna elements. The (e/g)NodeB is further connected to core network 110 (CN or next generation core NGC). Depending on the system, the counterpart on the CN side can be a serving gateway (S-GW, routing and forwarding user data packets), packet data network gateway (P-GW), for providing connectivity of user devices (UEs) to external packet data networks, or mobile management entity (MME), etc.
The user device (also called UE, user equipment, user terminal, terminal device, etc.) illustrates one type of an apparatus to which resources on the air interface are allocated and assigned, and thus any feature described herein with a user device may be implemented with a corresponding apparatus, such as a relay node. An example of such a relay node is a layer 2 relay or a layer 3 relay (self-backhauling relay) towards the base station.
The user device typically refers to a portable computing device that includes wireless mobile communication devices operating with or without a subscriber identification module (SIM), including, but not limited to, the following types of devices: a mobile station (mobile phone), smartphone, personal digital assistant (PDA), handset, device using a wireless modem (alarm or measurement device, etc.), laptop and/or touch screen computer, tablet, game console, notebook, and multimedia device. It should be appreciated that a user device may also be a nearly exclusive uplink only device, of which an example is a camera or video camera loading images or video clips to a network. A user device may also be a device having capability to operate in Internet of Things (IoT) network which is a scenario in which objects are provided with the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction. The user device (or in some embodiments a layer 3 relay node) is configured to perform one or more of user equipment functionalities. The user device may also be called a subscriber unit, mobile station, remote terminal, access terminal, user terminal or user equipment (UE) just to mention but a few names or apparatuses.
Various techniques described herein may also be applied to a cyber-physical system (CPS) (a system of collaborating computational elements controlling physical entities). CPS may enable the implementation and exploitation of massive amounts of interconnected ICT devices (sensors, actuators, processors microcontrollers, etc.) embedded in physical objects at different locations. Mobile cyber physical systems, in which the physical system in question has inherent mobility, are a subcategory of cyber-physical systems. Examples of mobile physical systems include mobile robotics and electronics transported by humans or animals.
It should be understood that, in
Additionally, although the apparatuses have been depicted as single entities, different units, processors and/or memory units (not all shown in
5G enables using multiple input-multiple output (MIMO) antennas, many more base stations or nodes than the LTE (a so-called small cell concept), including macro sites operating in co-operation with smaller stations and employing a variety of radio technologies depending on service needs, use cases and/or spectrum available. 5G mobile communications supports a wide range of use cases and related applications including video streaming, augmented reality, different ways of data sharing and various forms of machine type applications such as (massive) machine-type communications (mMTC), including vehicular safety, different sensors and real-time control. 5G is expected to have multiple radio interfaces, namely below 6 GHz, cmWave and mmWave, and also being integrable with existing legacy radio access technologies, such as the LTE. Integration with the LTE may be implemented, at least in the early phase, as a system, where macro coverage is provided by the LTE and 5G radio interface access comes from small cells by aggregation to the LTE. In other words, 5G is planned to support both inter-RAT operability (such as LTE-5G) and inter-RI operability (inter-radio interface operability, such as below 6 GHz-cmWave, below 6 GHz-cmWave-mmWave). One of the concepts considered to be used in 5G networks is network slicing in which multiple independent and dedicated virtual sub-networks (network instances) may be created within the same infrastructure to run services that have different requirements on latency, reliability, throughput and mobility.
The current architecture in LTE networks is fully distributed in the radio and fully centralized in the core network. The low latency applications and services in 5G require to bring the content close to the radio which leads to local break out and multi-access edge computing (MEC). 5G enables analytics and knowledge generation to occur at the source of the data. This approach requires leveraging resources that may not be continuously connected to a network such as laptops, smartphones, tablets and sensors. MEC provides a distributed computing environment for application and service hosting. It also has the ability to store and process content in close proximity to cellular subscribers for faster response time. Edge computing covers a wide range of technologies such as wireless sensor networks, mobile data acquisition, mobile signature analysis, cooperative distributed peer-to-peer ad hoc networking and processing also classifiable as local cloud/fog computing and grid/mesh computing, dew computing, mobile edge computing, cloudlet, distributed data storage and retrieval, autonomic self-healing networks, remote cloud services, augmented and virtual reality, data caching, Internet of Things (massive connectivity and/or latency critical), critical communications (autonomous vehicles, traffic safety, real-time analytics, time-critical control, healthcare applications).
The communication system is also able to communicate with other networks, such as a public switched telephone network or the Internet 112, or utilize services provided by them. The communication network may also be able to support the usage of cloud services, for example at least part of core network operations may be carried out as a cloud service (this is depicted in
Edge cloud may be brought into radio access network (RAN) by utilizing network function virtualization (NVF) and software defined networking (SDN). Using edge cloud may mean access node operations to be carried out, at least partly, in a server, host or node operationally coupled to a remote radio head or base station comprising radio parts. It is also possible that node operations will be distributed among a plurality of servers, nodes or hosts. Application of cloudRAN architecture enables RAN real time functions being carried out at the RAN side (in a distributed unit, DU 104) and non-real time functions being carried out in a centralized manner (in a centralized unit, CU 108).
It should also be understood that the distribution of labor between core network operations and base station operations may differ from that of the LTE or even be non-existent. Some other technology advancements probably to be used are Big Data and all-IP, which may change the way networks are being constructed and managed. 5G (or new radio, NR) networks are being designed to support multiple hierarchies, where MEC servers can be placed between the core and the base station or nodeB (gNB). It should be appreciated that MEC can be applied in 4G networks as well.
5G may also utilize satellite communication to enhance or complement the coverage of 5G service, for example by providing backhauling. Possible use cases are providing service continuity for machine-to-machine (M2M) or Internet of Things (loT) devices or for passengers on board of vehicles, or ensuring service availability for critical communications, and future railway/maritime/aeronautical communications. Satellite communication may utilize geostationary earth orbit (GEO) satellite systems, but also low earth orbit (LEO) satellite systems, in particular mega-constellations (systems in which hundreds of (nano)satellites are deployed). Each satellite 106 in the mega-constellation may cover several satellite-enabled network entities that create on-ground cells. The on-ground cells may be created through an on-ground relay node 104 or by a gNB located on-ground or in a satellite.
It is obvious for a person skilled in the art that the depicted system is only an example of a part of a radio access system and in practice, the system may comprise a plurality of (e/g)NodeBs, the user device may have an access to a plurality of radio cells and the system may comprise also other apparatuses, such as physical layer relay nodes or other network elements, etc. At least one of the (e/g)NodeBs or may be a Home (e/g)nodeB. Additionally, in a geographical area of a radio communication system a plurality of different kinds of radio cells as well as a plurality of radio cells may be provided. Radio cells may be macro cells (or umbrella cells) which are large cells, usually having a diameter of up to tens of kilometers, or smaller cells such as micro-, femto- or picocells. The (e/g)NodeBs of
For fulfilling the need for improving the deployment and performance of communication systems, the concept of “plug-and-play” (e/g)NodeBs has been introduced. Typically, a network which is able to use “plug-and-play” (e/g)Node Bs, includes, in addition to Home (e/g)NodeBs (H(e/g)nodeBs), a home node B gateway, or HNB-GW (not shown in
One of the features supported by 5G New Radio is the use of configured grant Physical Uplink Shared Channel (PUSCH) resources. According to NR, the gNB (i.e., the access node) can dynamically allocate resources, in the uplink, to UEs (i.e., terminal devices) using the Cell Radio Network Temporary Identifier (C-RNTI) on Physical Downlink Control Channel(s) (PDCCH(s)). C-RNTI is a unique identifier used for identifying RRC connection and scheduling dedicated to a particular UE. A UE always monitors the PDCCH(s) in order to find possible grants for uplink transmission when its downlink reception is enabled. In addition, with Configured Grants, the gNB is able to (semi-statically) allocate uplink resources for the initial hybrid automatic repeat request (HARQ) transmissions to UEs. Two types of configured uplink grants are defined. With Type 1 configured grant, Radio Resource Control (RRC) directly provides the configured uplink grant (including the periodicity). With Type 2 configured grant, RRC defines the periodicity of the configured uplink grant while PDCCH addressed to Configured Scheduling RNTI (CS-RNTI) can either signal and activate the configured uplink grant, or de-activate it. In other words, a PDCCH addressed to CS-RNTI uplink grant can be implicitly reused according to the periodicity defined by RRC, until deactivated.
When a configured uplink grant is active, if the UE cannot find a dynamic uplink (UL) grant using C-RNTI/CS-RNTI on the PDCCH(s), an uplink transmission according to the configured uplink grant can be made. Otherwise, if the UE finds a dynamic UL grant using C-RNTI/CS-RNTI on the PDCCH(s), the PDCCH allocation overrides the configured uplink grant. Retransmissions other than repetitions are explicitly allocated via PDCCH(s).
It should be noted that a similar mechanism as described in the previous paragraph for 5G NR is also supported in LTE. In LTE, a similar mechanism for licensed bands is UL semi-persistent scheduling (SPS). Moreover, the mechanism which provides autonomous UL transmissions on unlicensed spectrum (SCells in Licensed Assisted Access) is called Autonomous UL Access (AUL) and has the following properties:
AUL also allows for configuring a set of starting positions for UEs with a very fine raster within the first SC-FDMA symbol of a subframe: 16, 25, 34, 43, 52, or 61 microseconds after the subframe boundary, or at the beginning of symbol #1. Since all UEs perform Listen-Before-Talk (LBT) operation prior to the AUL transmission to determine whether the channel is free, different starting point allow for, e.g., prioritizing transmissions for certain UEs (by assigning an earlier starting point) and reducing the number of collisions.
Further, MulteFire 1.1 also supports grant-free UL (GUL). The solution is similar to the AUL described above.
The embodiments to be described below utilize a configured (uplink) grant scheme (as described above) for overcoming or alleviating problems encountered especially when using Ultra-Reliable Low Latency Communication (URLLC) in certain demanding radio propagation environment. One such demanding radio propagation environment is a factory floor. Many industrial automation systems employ currently or are envisioned to employ in the future wireless communications for control and/or other functions. Considering the high precision work performed, for example, by industrial robotics system for laser welding or cutting, low latency and high reliability are of high importance.
Multiple challenges in view of radio propagation persist in a factory floor environment. Firstly, machinery on the factory floor may cause interference. Secondly, multiple bulky metallic structures and objects, some of which may even be non-stationary, may be located on the factory floor causing blockages and/or significant attenuation (i.e., large-scale fading). Thirdly, collisions of the grant-free transmissions as well as interference from other cells/transmissions further deteriorate the performance of the communications links. All of the aforementioned factors contribute to the deterioration of the signal detection rate which may easily fall below what is an acceptable level for URLLC.
The communications system 200 comprises one or more access nodes 201, 202 each of which may correspond to element 104 of
The access nodes 201, 202 may be connected via radio (access) links to one or more terminal devices 211, 212, 213, 214, 215, 216, 217, 218, 219. This link is called an access link. Each terminal device 290 may correspond to either of elements 100, 103. Thus, the access nodes may provide one or more terminal devices (user equipment, UEs) with wireless access to other networks such as the Internet, either directly or via a core network. Said wireless access may be provided directly (using a single “hop”) or via multiple “hops” where one or more terminal devices 211, 212, 213, 214, 215, 216, 217, 218, 219 act as relay nodes.
In embodiments where the communications system 200 corresponds to an industrial facility, the terminal devices may be any industrial equipment capable of connecting to a wireless network. Thus, the one or more terminal devices 211, 212, 213, 214, 215, 216, 217, 218, 219 (or at least some of them) may not have any strict battery constraints and they may be static or moving at a moderate velocity (e.g., a forklift). Further, at least some of the terminal devices may be configured to communicate not only with the access nodes 201, 202 but also between with each other (e.g., communication between a control unit and a “functional” unit such as a welding unit).
The radio propagation environment of the communication system 200 comprises one or more obstacles 221, 222, 223, 224, 225. Said one or more obstacles 221, 222, 223, 224, 225 when located between transmitting and receiving network nodes (i.e., terminal devices or access nodes) may cause large-scale fading effects (blockage or shadowing) which deteriorate the signal quality of the corresponding link. The line-of-sight path may, in some cases, be fully blocked by an obstacle. Further, the one or more obstacles may cause unwanted reflections.
The shape and type of the one or more obstacles may vary. Said one or more obstacles may comprise, for example, large industrial machinery, assembly line structures, metal barriers or walls, metallic scaffolding, stored raw materials, products or shipping containers. Moreover, said one or more obstacles may comprise one or more moving obstacles such as forklifts and other vehicles.
While only a single (best) connection option is shown for each terminal device 211, 212, 213, 214, 215, 216, 217, 218, 219 in
The timely delivery of single packet on a multi-hop approach in a radio propagation environment as depicted in
The process of
Referring to
Information on radio link measurements between terminal devices and between the access node and the terminal devices may be maintained in a database comprised in or connected to the access node. The terminal devices may be configured to report radio link measurements periodically to the access node and/or the access node may request the terminal devices to perform radio link measurements (as will be discussed in more detail in relation to
After the selection has been made, the access node configures, in block 302, each of the one or more terminal devices by generating configuration information and transmitting the configuration information to them. The configuration (information) may be defined differently for different terminal devices based on, for example, radio link qualities defined in the radio link measurements. The configuration information may comprise at least Modulation Coding Scheme (MCS), PRB allocation and Radio Network Temporary Identifier (RNTI) used by the source terminal device. In an embodiment, the configuration information comprises one or more of information on the primary PUSCH resources to be used in decoding, information on secondary PUSCH resources to be used in transmitting, a MCS, a PRB allocation, a first RNTI used by the source terminal device and a second RNTI to be used by the configured terminal device (which may or may not be equal to the RNTI used by the source terminal device).
Specifically, the access node may configure each terminal device of the one or more terminal devices at least to decode (blindly) any received primary (1st) PUSCH resources (i.e., to decode transport blocks on the primary PUSCH resources). The information on the primary PUSCH resource configuration (i.e., information on which PUSCH resources to decode) may be included in the transmitted configuration information. The RNTI used by the source terminal device and comprised in the configuration information may be used in the decoding. The primary PUSCH resources may be primary Configured Grant, CG, PUSCH resources or dynamically scheduled PUSCH resources. In the latter case, the terminal device may be provided in the configuration information the related RNTI and the Physical Downlink Control Channel, PDCCH, monitoring configuration of the source terminal device. Further, if the decoding is successful, each terminal device may be configured to transmit a transport block corresponding to the decoded primary PUSCH resource on a secondary (2nd) PUSCH resource to a target network node. Further, each terminal device may be configured, using the configuration information, to transmit the transport block using a pre-defined starting position (i.e., to initiate the transmission at different pre-defined time instances). The starting position may be defined here and in the following as a starting position for transmission in time relative to the slot boundary or starting time of the associated slot. The access node may configure the one or more terminal devices so that the secondary (2nd) PUSCH resource and the pre-defined starting position are different for each of the one or more terminal devices. The pre-defined starting position for each terminal device may be determined based, e.g., on the radio link measurements or more specifically on values of a pre-defined metric indicating link quality towards the target network node (calculated based on the radio link measurements). The secondary PUSCH resource may be a secondary CG PUSCH resource (different from the primary CG PUSCH resource). The target network node may be the access node or one of the one or more terminal devices (which is, in turn, configured to relay the transport block to the access node, possible via one or more terminal devices). At least one terminal device may be configured by the access node to use the access node itself as the target network node.
The access node receives or detects, in block 303, at least one transport block transmitted from the source terminal device via one or more terminal devices of the one or more terminal devices on one or more secondary PUSCH resources (i.e., secondary PUSCH resources assigned for the corresponding terminal devices). Obviously, the access node may also still detect the original transport block transmitted by the source terminal device on the primary PUSCH resource without relaying.
While in some embodiments, all the terminal devices may be configured to perform relaying with two hops (i.e., transmission from source terminal device to the relaying terminal device and from the relaying terminal device to the access node), in other embodiments three or more hops may be defined for at least some relaying links. For the two-hop relaying, the primary PUSCH resource may be the same primary PUSCH resource used by the source terminal device for all configured terminal devices while the secondary PUSCH resource may be different for at least some of the configured terminal devices. In the cases where three or more hops are used for at least some relaying links, the primary PUSCH resource may be a PUSCH resource used by the source terminal device or a preceding terminal device in the relay chain for transmission and the secondary PUSCH resource may be a PUSCH resource used by the access node or a subsequent terminal device in the relay chain for reception.
In some embodiments, the access node may configure, in block 302, each of the one or more terminal devices with the configuration information to perform the decoding only for Ultra-Reliable Low Latency Communication, URLLC, transmissions. In some such embodiments, different source terminal devices may use different primary (CG) PUSCH resources while different links (i.e., sidelinks/uplinks) from the same source terminal, which may be separated based on used RNTI, may use the same secondary (CG) PUSCH resource. Alternatively or in addition, the access node may configure, in block 302, each of the one or more terminal devices with the configuration information to perform the decoding only for transmissions originating from the source terminal device based on the decoded primary PUSCH resources and/or a first Radio Network Temporary Identifier, RNTI, used in the decoding.
In some embodiments, the one or more terminal devices may be configured, in block 302, by the access node using the configuration information to use in the transmitted transport block on the secondary PUSCH resource the same RNTI which is used also by the source terminal device on the primary PUSCH resource. By using the same RNTI in the repeated transmission, the target network node is easily able to identify the source terminal device (even in the case that multiple source terminal devices use the same PUSCH resource in transmission) and/or the target terminal device (in the case of sidelink and uplink from the same terminal device). In such embodiments and in embodiments where multiple hops are employed, the original transmission and the hops need to be separated by using different PUSCH resources to prevent the relaying of already relayed information on a parallel hopping-link path. The PUSCH resources may be different in frequency and/or in time so that the original transmission and each of the hops use different resources for transmission of current transport block and for possible consecutive transport block(s).
In an alternative solution to the embodiment described in the previous paragraph, the one or more terminal devices for relaying/repeating may use a second RNTI that is configured to be used solely for repeating/relaying the transmission from the source terminal device. Said second RNTI may be specific to each particular repeated/relayed link as well as to the hop order (i.e., 1st hop, 2nd hop, 3rd hop etc.) in case of multiple hops.
In yet another alternative embodiment, each of the multi-hop transmissions may further include some related control information, e.g., defining the source, time instant, hopping-link-path identification and/or hop number (within the hopping-link-path). Such relaying related information may be carried as Uplink Control Information (UCI) mapped together with the relayed (re-)transmission. Such information may be used to identify and coordinate the transmission of multiple hopping links, e.g., preventing the relaying of already relayed information on a parallel hopping-link path.
In some embodiments, each terminal device may be involved in repeating/relaying signals for multiple links (i.e., for multiple source terminal devices and/or multiple access nodes). The terminal devices may be configured to separate links originating from different source terminal devices as well as links originating from the same source terminal device but for different target network nodes (e.g., sidelink and uplink) based on different (secondary) PUSCH resource and/or different RNTIs. Optionally, one or more of DMRS, MCS and PRB allocation may also be used for the separating.
It should be noted that the embodiments may primarily seek to increase reliability with short latency, not cell coverage extension. Hence, normal transmission may use C-RNTI which does not trigger the relaying while specific RNTI may be used for transmissions requiring or benefiting from the relaying. For example, data that is sensitive from security viewpoint may use normal transmission.
Referring to
After the terminal device has been configured, the terminal device acts according to its configuration by performing the following. In response to receiving, in block 403, a primary PUSCH resource (as defined in the configuration information), the terminal device decodes (or tries to decode), in block 404, the primary PUSCH resource. The decoding may be based on information on the packets transmitted by the source terminal device comprised in the configuration information (e.g., RNTI, MCS, PRB allocation). In response to the decoding being successful in block 405, the terminal device causes transmitting, in block 406, a transport block corresponding to the decoded primary PUSCH resource on a secondary PUSCH resource (as defined in the configuration information) to the target network node (i.e., another terminal device or the access node). If the decoding is determined to be unsuccessful in block 405, the terminal device may simply ignore the received primary PUSCH resource and wait for further transmissions of the primary PUSCH resource (i.e., process may proceed to block 403). As multiple terminal devices may have been configured to relay packets from the source terminal device as described in relation to
The terminal device may be assumed, in most embodiments, to operate according to half-duplex constraint, i.e., it is not capable of transmitting and receiving at the same time on the same uplink band. If the terminal device has a valid uplink grant for the time defined for primary PUSCH reception and detection, the terminal device may be configured to prioritize PUSCH transmission.
In
In addition to measuring terminal device to terminal device links, the access node may also measure the uplink channels (i.e., their link quality) for the same terminal devices. To this end, the access node causes transmitting, in block 504, to the one or more terminal devices a request for transmitting a reference signal to the access node. The one or more terminal may be the one or more terminal discovered in block 501. Subsequently, the access node detects and measures, in block 505, one or more reference signals transmitted from the one or more discovered terminal devices.
Some or all of the actions performed in block 501 to 505 may be repeated periodically. As in a factory floor scenario as described above many of the terminal devices are static, said actions may be repeated relatively infrequently in such a scenario. The acquired up-to-date measurement results (relating both to terminal device to terminal device links as well as to uplinks) may be stored to a memory or a database. This may be carried out by a logical entity called topology manager. In some embodiments, only one of the two processes relating to blocks 502, 503 and blocks 504, 505 may be carried out.
The access node determines, in block 506, whether one or more criteria for triggering or initiating the relaying is satisfied. The criteria may be any criteria for initiating the selecting as described in relation to
The actions performed in block 507 may correspond to the actions described in relation block 302 of
The step of configuring of the one or more terminal devices (i.e., block 302 of
The measurement results of the radio link measurements acquired in blocks 501 to 505 may be employed in configuring the one or more terminal devices using the aforementioned pre-defined starting positions in the following way. Using the measurement results, the one or more terminal devices may be, first, arranged based on values of a pre-defined metric indicating link quality towards the target network node. Specifically, the pre-defined metric may indicate radio link quality between the terminal device and the target network node or link quality between the source terminal device and the target network node via at least the terminal device in question. A certain number of values of the pre-defined secondary PUSCH starting positions may be pre-defined. The pre-defined starting positions may be, for example, relative to the slot boundary or to the start of the slot and may be defined in multiples of a symbol or in fractions of a symbol. The symbol may be, for example, a CP-OFDMA or a DFT-S-OFDMA symbol. The starting positions may be confined within a single slot. The smallest pre-defined value of the pre-defined starting position (i.e., a first or earliest starting position) may be assigned to the terminal device with the highest link quality, the second smallest pre-defined value of the pre-defined starting position (i.e., a second or second earliest starting position) may be assigned to the terminal device with the second highest link quality and so on until all the terminal devices have been assigned a pre-defined starting position for the relaying using a secondary CG PUSCH resource. The pre-defined starting position assigned for a terminal device may be, for example, inversely proportional to the metric indicating link quality towards the target network node or defined via a monotonically decreasing function of the metric indicating link quality or based on the order of values of the pre-defined metric indicating link quality for the one or more terminal devices (selected in block 507) so that the highest value of the pre-defined metric corresponds to a first (i.e., earliest) starting position and the lowest value of the pre-defined metric corresponds to a last starting position.
In some embodiments, the access node may also cause transmitting, in block 509, (source) configuration information to the source terminal device (in addition to transmitting configuration information to the one or more terminal devices to be used for relaying as discussed above). Specifically, the access node may configure the source terminal device, by transmitting at least the first RNTI to the source terminal device, to use the first RNTI for transmitting on the primary PUSCH resource. The first RNTI may be a RNTI used by the source terminal device only for relaying transmissions. During normal (non-relaying) operation, the source terminal device may be configured (by default) to use a C-RNTI for transmissions.
The actions performed in block 510 may correspond to the actions described in relation block 303 of
In some embodiments, MCS for the one or more terminal devices may be configured by the access node using the configuration information separately for each relaying terminal device with different starting position.
In some embodiments, the measurement results used for determining the pre-defined starting positions for the one or more terminal devices may be measurement results available at the time of Radio Resource Control (RRC) configuration.
With the configuration information generated according to the definition described in the previous paragraph, the terminal devices associated with better link quality towards the target network node are configured to transmit the transport block before the terminal devices associated with worse link quality towards the target network node. This enables the terminal devices configured to transmit later detect whether the secondary CG PUSCH resource is already occupied (and the message of interest is already being repeated). This functionality is illustrated with
Referring to
After the primary PUSCH resource has been decoded successfully in block 605, the terminal device selects, in block 606, a secondary (CG) PUSCH resource based on its configuration to be used for transmission. However, before the transmission the terminal device determines, in block 607, whether the selected secondary (CG) PUSCH resource is already occupied. The determining in block 607 may be based on a Listen-Before-Talk, LBT, procedure or a sequence detection procedure. In response to the selected secondary (CG) PUSCH resource being available (i.e., not occupied) in block 608, the terminal device causes transmitting, in block 609, a transport block corresponding to the decoded primary PUSCH resource on the selected secondary (CG) PUSCH resource to the target network node (i.e., a terminal device or the access node as defined in the configuration information) starting at the configured starting position. If the selected secondary (CG) PUSCH resource is occupied in block 608, the terminal device selects, in block 606, another (alternative) secondary (CG) PUSCH resource for relaying and determines whether said alternative secondary (CG) PUSCH resource is occupied in block 607, 608. Actions pertaining to blocks 606, 607, 608 are repeated until an available secondary (CG) PUSCH resource is found in block 608. Then, the terminal device causes transmitting, in block 609, a transport block corresponding to the decoded primary PUSCH resource on the selected alternative secondary (CG) PUSCH resource to the target network node starting at the configured starting position. If none of the configured secondary (CG) PUSCH resources is determined to be available in blocks 606 to 608, terminal device drops the decoded first (CG) PUSCH and moves back to receiving the next primary PUSCH resource in block 603.
In some alternative embodiments, the access node may allocate different parallel secondary PUSCH resources for different relay paths (i.e., for different relaying terminal devices) to guarantee the reception of the transport block over multiple relaying link paths. In such embodiments, the terminal devices may or may not be configured to check, in blocks 607, 608, whether the particular PUSCH resource to be used for transmission is occupied. This functionality is discussed in more detail in relation to
As described in relation to
The LBT approach may follow the corresponding AUL procedure as discussed above, adapted to the used subcarrier spacing (SCS). For example, supporting three starting position may take 1-2 symbols for 30 or 60 kHz SCS. However, LBT approach prevents that other signals (e.g., scheduled PUSCH) are frequency-division-multiplexed with the configured grant PUSCH resources. The LBT has the disadvantage of being able to be blocked simply by interference (as required on unlicensed band, but not on licensed band), as will be discussed in relation to
For a first terminal device with the first starting position, no detection has to be performed as no terminal device is configured to transmit before said first terminal device. Therefore, all the symbols of the corresponding PRB may be used for transmitting the transport block on the secondary CG PUSCH resource assuming that the decoding of the primary CG PUSCH resource transmitted by the source terminal device was successful. The symbols may be, e.g., CP-OFDM or DFT-S-OFDM symbols. The transmission of the secondary CG PUSCH resource starts with a transmission of a front-loaded DMRS 701 to be used for sequence detection by the terminal devices with later starting positions, as well as for channel estimation by the target network node.
Before transmission, the second terminal device with the second starting position needs to determine whether the first terminal device is already transmitting with the secondary CG PUSCH resource (i.e., the secondary CG PUSCH resource with the first starting position). To achieve this, the second terminal device is configured by the access node to detect a pre-defined DMRS sequence (defined, e.g., by a root sequence, length and/or cyclic shifts) during a pre-defined sequence detection phase 704 associated with the starting position. Specifically, the sequence detection phase of the second terminal device is configured to be aligned with the DMRS transmission 701 for the first terminal device. The sequence detection phase may be, for example, based on comparing a metric indicating the sequence detection energy/accuracy/quality to a pre-defined and/or preconfigured threshold. If the pre-defined threshold is exceeded, the second terminal device considers the secondary CG PUSCH resource occupied and thus needs to transmit the transport block on an alternative secondary CG PUSCH resource. Otherwise, the second terminal device considers the secondary CG PUSCH resource unoccupied (i.e., available) and consequently the second terminal device may proceed with transmitting the transport block on the secondary CG PUSCH. In either case, the transmission of the secondary CG PUSCH resource in question starts also here with a transmission of a front-loaded DMRS 702 at the second starting position.
The sequence detection procedure for the third terminal device corresponding to the third starting position is in many ways similar to the sequence detection procedure for the second terminal device though slightly more complicated. The third terminal device is configured to detect, in symbol 705, whether the secondary PUSCH resource is occupied in a symbol aligned with the DMRS transmission of the first terminal device, similar to as discussed above for the second terminal device. In the case that the secondary PUSCH resource with the first starting position is deemed unoccupied, the third terminal device is configured to detect, in symbol 706, whether the secondary PUSCH resource with the second starting position is occupied in a symbol aligned with the DMRS transmission of the second terminal device. The second sequence detection phase may be carried out in a similar manner to the first sequence detection phase. Here, it is assumed that the secondary PUSCH resources with both the first and the second starting positions are unoccupied, Thus, after the first and second sequence detection phases showing the secondary PUSCH resource to be unoccupied the third terminal device causes transmitting the transport block on a secondary CG PUSCH resource with the third starting position. The transmission of the secondary CG PUSCH resource in question starts at the third starting position with a transmission of a front-loaded DMRS 703. In
As illustrated in
In some embodiments, short mini-slots (with less than 14 symbols) may be used instead of the 14-symbol slots as shown in
In
In some embodiments, the access node may configure at least two of the one or more terminal devices with the configuration information to perform the transmitting using two or more secondary PUSCH resources parallel in frequency. This functionality is illustrated in
In
In some embodiments (especially in embodiments not based on URLLC), multiple terminal devices (source terminal devices or repeating or relaying terminal devices) may be configured with the same CG PUSCH resources and consequently collisions may occur. Depending on physical locations of the colliding terminal devices relative to each other and relative to a receiver, the collision may or may not result in a failure of the decoding for a particular receiver (i.e., a repeating terminal device or an access node). Therefore, a repeating terminal device may, in some cases, be able to correctly decode the transport block from the source terminal device even if the decoding fails at the target network node (i.e., an access node or another repeating terminal device). To avoid repeated collisions also on the 2nd hop repetitions, the access node may configure overbooking of the CG PUSCH resources so that colliding source terminal devices do not have 2nd hop associated CG PUSCH resources (i.e., secondary CG PUSCH resources) colliding. Instead, the transport blocks potentially colliding on the 2nd hop CG PUSCH resources would originate from source terminal devices not using overlapping (primary) CG PUSCH resources for transmission.
In some embodiments, an uplink channel other than the PUSCH may be employed. In other words, the (CG) PUSCH resources (primary and/or secondary) as used in relation to any embodiments may be (physical) uplink resources of a (physical) uplink channel other than the PUSCH. Said (physical) uplink resources may have any properties discussed in relation to (CG) PUSCH resources.
The proposed solutions according to embodiments discussed above provide multiple advantages over prior art. The embodiments provide a simple solution for achieving diversity against large-scale fading. In the proposed solution, a larger number of terminal devices may be configured to detect the transmission from the source terminal device than there are 2nd hop resources which improves resource efficiency. The 2nd hop may be transmitted by a pre-defined number of terminal devices (which decoded the 1st hop successfully), in the order of 2nd hop link qualities. Moreover, the proposed solution is to a large extent built on top of existing or upcoming NR functionalities meaning that it may be implemented easily.
In some embodiments, the actions performed by the access node (i.e., a network node or network element providing wireless access) according to any embodiments as described above may be performed fully or partly by another network node or network element or even by multiple network nodes/elements. For example, said actions (or at least some of said actions) may be performed, instead of the access node, by a core element or by an edge cloud (element).
The blocks, related functions, and information exchanges described above by means of
The techniques and methods described herein may be implemented by various means so that an apparatus/device configured to support relaying based on at least partly on what is disclosed above with any of
For example, one or more of the means described above may be implemented in hardware (one or more devices), firmware (one or more devices), software (one or more modules), or combinations thereof. For a hardware implementation, the apparatus(es) of embodiments may be implemented within one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, logic gates, decoder circuitries, encoder circuitries, other electronic units designed to perform the functions described herein by means of
Referring to
Referring to
Referring to
Referring to
Referring to
Referring to
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 implementations in only analog and/or digital circuitry, and (b) combinations of hardware circuits and software (and/or firmware), such as (as applicable): (i) a combination of analog and/or digital hardware circuit(s) with software/firmware and (ii) any portions of hardware processor(s) with software, including digital signal processor(s), software, and memory(ies) that work together to cause an apparatus, such as a terminal device or an access node, to perform various functions, and (c) hardware circuit(s) and processor(s), such as a microprocessor(s) or a portion of a microprocessor(s), that requires 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 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 a portion of a hardware circuit 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 element, a baseband integrated circuit for an access node or a terminal device or other computing or network device. In embodiments, the at least one processor, the memory, and the computer program code form processing means or comprises one or more computer program code portions for carrying out one or more operations according to any one of the embodiments of
Embodiments as described may also be carried out in the form of a computer process defined by a computer program or portions thereof. Embodiments of the methods described in connection with
Even though the invention has been described above with reference to examples according to the accompanying drawings, it is clear that the invention is not restricted thereto but can be modified in several ways within the scope of the appended claims. Therefore, all words and expressions should be interpreted broadly and they are intended to illustrate, not to restrict, the embodiment. It will be obvious to a person skilled in the art that, as technology advances, the inventive concept can be implemented in various ways. Further, it is clear to a person skilled in the art that the described embodiments may, but are not required to, be combined with other embodiments in various ways.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/EP2018/073753 | 9/4/2018 | WO | 00 |
