CN116438881A - Coverage enhancement and system efficiency by UE - Google Patents

Abstract

A user equipment may use a soft acknowledgement/negative acknowledgement (ACK/NACK) report to indicate a desired number of repetitions of a Physical Downlink Shared Channel (PDSCH). In some embodiments, the user equipment may generate a soft ACK/NACK report comprising a plurality of bits. The plurality of bits may be encoded to indicate to the network node whether the number of allocated repetitions is sufficient, redundant or insufficient, and how many repetitions the UE is further needed or desired.

Description

Coverage enhancement and system efficiency by UE

Technical Field

The present application relates generally to wireless communication systems, and more particularly to techniques for a user equipment to indicate a desired number of PDSCH repetitions.

Background

Wireless mobile communication technology uses various standards and protocols to transfer data between a base station and a wireless mobile device. Wireless communication system standards and protocols may include 3 rd generation partnership project (3 GPP) Long Term Evolution (LTE) (e.g., 4G) or new air interface (NR) (e.g., 5G); the Institute of Electrical and Electronics Engineers (IEEE) 802.16 standard, which is commonly referred to by industry organizations as Worldwide Interoperability for Microwave Access (WiMAX); and the IEEE 802.11 standard for Wireless Local Area Networks (WLANs), which is commonly referred to by industry organizations as Wi-Fi. In a 3GPP Radio Access Network (RAN) in an LTE system, a base station may include a RAN Node, such as an evolved Universal terrestrial radio Access network (E-UTRAN) Node B (also commonly referred to as an evolved Node B, enhanced Node B, eNodeB, or eNB) and/or a Radio Network Controller (RNC) in the E-UTRAN, that communicates with wireless communication devices called User Equipment (UE). In a fifth generation (5G) wireless RAN, the RAN nodes may include 5G nodes, NR nodes (also referred to as next generation Node bs or G Node bs (gnbs)).

The RAN communicates between RAN nodes and UEs using Radio Access Technology (RAT). The RAN may comprise a global system for mobile communications (GSM), enhanced data rates for GSM evolution (EDGE) RAN (GERAN), universal Terrestrial Radio Access Network (UTRAN), and/or E-UTRAN, which provides access to communication services through a core network. Each of the RANs operates according to a particular 3GPP RAT. For example, GERAN implements GSM and/or EDGE RATs, UTRAN implements Universal Mobile Telecommunications System (UMTS) RATs or other 3gpp RATs, e-UTRAN implements LTE RATs, and NG-RAN implements 5G RATs. In some deployments, the E-UTRAN may also implement the 5G RAT.

The frequency band of 5G NR can be divided into two different frequency ranges. The frequency range 1 (FR 1) includes frequency bands below 6GHz, some of which may be used by previous standards, but may potentially be extended to cover potential new spectrum products of 410MHz to 7125 MHz. The frequency range 2 (FR 2) includes the frequency band of 24.25GHz to 52.6 GHz. The frequency band in the millimeter wave (mmWave) range of FR2 has a shorter range but a higher available bandwidth than the frequency band in FR 1. The skilled person will appreciate that these frequency ranges provided by way of example may vary from time to time or region to region.

Drawings

For ease of identifying discussions of any particular element or act, one or more of the most significant digits in a reference numeral refer to the figure number that first introduces that element.

Fig. 1 is a simplified signal flow diagram of an exemplary process for transmitting an ACK/NACK report according to one embodiment.

Fig. 2 is a flowchart of a method for a UE to indicate a desired number of repetitions of a PDSCH according to the first embodiment.

Fig. 3 is a flowchart of a method for a UE to indicate a desired number of repetitions of a PDSCH according to a second embodiment.

Fig. 4 is a flowchart of a method for a gNB to determine a desired number of repetitions of a PDSCH, according to one embodiment.

Fig. 5 illustrates a flowchart of a method of indicating a desired increase in the number of symbols (N1) between the end of PDSCH transmission and the beginning of PUCCH transmission, according to one embodiment.

Fig. 6 illustrates an exemplary service-based architecture according to some embodiments.

Fig. 7 illustrates a UE according to one embodiment.

Fig. 8 illustrates a network node according to one embodiment.

Detailed Description

Coverage is one of the key factors that operators consider when commercializing cellular communication networks, as it directly affects quality of service as well as capital expenditure (CAPEX) and operating costs (OPEX). Although coverage is critical to the success of new air interface (NR) commercialization, so far no comprehensive coverage assessment and comparison with legacy RATs considering all NR specification details has been made.

NR is designed to operate at much higher frequencies, such as 28GHz or 39GHz in frequency range 2 (FR 2), compared to Long Term Evolution (LTE). Furthermore, many countries are providing more spectrum over frequency range 1 (FR 1), such as 3.5GHz, which is typically higher than LTE or 3G. Due to the higher frequencies, it is inevitable that the wireless channel will experience higher path loss, making it more challenging to maintain sufficient quality of service at least equal to that of conventional Radio Access Technologies (RATs).

Embodiments herein describe systems, apparatuses, and methods for achieving coverage enhancement of NR using repetition and feedback from user equipment. In some embodiments herein, the UE uses a soft acknowledgement/negative acknowledgement (ACK/NACK) report to indicate a desired number of repetitions of a Physical Downlink Shared Channel (PDSCH) transmission. In some embodiments herein, a User Equipment (UE) uses a soft ACK/NACK to indicate an increase in the number of symbols between the end of a PDSCH transmission and the beginning of a Physical Uplink Control Channel (PUCCH) transmission.

Various operations will be described as multiple discrete operations in turn, in a manner that is most helpful in understanding the present disclosure. However, the order of description should not be construed as to imply that these operations are necessarily order dependent. In particular, these operations need not be performed in the order of presentation.

Additional details and examples are provided with reference to the following figures. Embodiments of the present disclosure may be understood by reference to the following drawings, in which like elements are indicated by like numerals throughout. The components of the disclosed embodiments of the present invention, as generally described and illustrated in the figures herein, can be arranged and designed in a wide variety of different configurations. Thus, the following detailed description of the embodiments of the systems and methods of the present disclosure is not intended to limit the scope of the disclosure, as claimed, but is merely representative of possible embodiments.

Fig. 1 is a simplified signal flow diagram of an exemplary process for transmitting an ACK/NACK report according to one embodiment. As shown, a network node 106 (e.g., a next generation NodeB (gNB)) may transmit downlink communications to a UE 104. The downlink communication may be PDSCH 108.

In some embodiments, the network node 106 transmits PDSCH repeated packets (bundles). The more repetitions the network node 106 transmits, the more likely the UE 104 is to receive and be able to decode the PDSCH 108, thereby improving coverage. However, repetition comes at the cost of reduced system efficiency.

Embodiments herein balance coverage and efficiency by having the UE 104 transmit additional information in the soft ACK/NACK report 110. For example, the network node 106 may be set to an initial number of repetitions of transmitting the PDSCH 108, and the UE 104 may indicate whether the initial number of repetitions is sufficient. If the initial number of repetitions is sufficient, the UE 104 includes an ACK message in the soft ACK/NACK report 110 indicating that the UE is able to successfully decode the transport blocks within the PDSCH 108. If the initial number of repetitions is insufficient, the UE 104 includes an ACK message in the soft ACK/NACK report 110 indicating that the UE is not able to decode the transport blocks within the PDSCH 108 and requesting the desired additional number of repetitions in the retransmission. Fig. 2-3 include additional details regarding embodiments in which the UE 104 indicates a desired number of repetitions.

The network node 106 determines whether the soft ACK/NACK report 110 includes a NACK message. If there is a NACK 102, the network node 106 retransmits the PDSCH 112. The retransmitted PDSCH 112 includes the number of repetitions indicated in the NACK message that the UE 104 expects.

In addition, in some embodiments, the UE 104 may use the soft ACK/NACK report 110 to indicate an increase in the number of symbols (N1) between the end of PDSCH transmission and the beginning of PUCCH transmission. If the network node 106 detects an indication to increase N1 from the soft ACK/NACK report 110, the network node 106 may extend the time to ensure that the UE 104 has enough time to perform the processing. Fig. 5 includes additional details regarding the UE indicating a desire to increase N1.

Fig. 2 is a flow chart of a method 200 for a UE to indicate a desired number of repetitions of a PDSCH according to a first embodiment. For PDSCH repetition, the UE using method 200 may provide soft ACK/NACK reporting instead of single bit ACK/NACK for repeated packets. The soft ACK/NACK report may allow the UE to provide more information to the gNB as to whether the number of allocated repetitions is sufficient, redundant, or insufficient, and how many repetitions the UE needs or expects again.

In the illustrated embodiment, the UE receives PDSCH repeated packets 202 from the gNB. The UE may attempt to decode the transport block 204 within the PDSCH repeated packet. The UE may prepare a soft ACK/NACK report to inform the gNB whether the UE is able to successfully decode the transport block 206 or whether the UE needs the gNB to retransmit the PDSCH. In addition, the soft ACK/NACK report may include additional information indicating whether the number of repetitions of the PDSCH is sufficient, redundant, or insufficient, and how many repetitions the UE needs or desires again.

The format of the soft ACK/NACK report may depend on whether the transport block was successfully decoded. Additionally, in some embodiments, the ACK/NACK report may use different resources based on whether it is an acknowledgement message or a negative acknowledgement message.

For example, if the UE is able to successfully decode the transport block 206, the UE may generate a soft ACK/NACK report 208 with a single bit. For example, when the UE is able to decode a transport block within a PDSCH repeated packet, the UE may generate and send a single bit ACK message on PUCCH resource a.

If the UE fails to decode the transport block, the UE may generate 210 and send a soft ACK/NACK report with a multi-bit NACK message. For example, the UE may send two or more bits instead of a single bit NACK message on PUCCH resource B. In some embodiments, the bits may be mapped to different code points that indicate the additional number of repetitions that the UE expects to successfully decode the transport block. The gNB receiving the soft ACK/NACK report may add additional repetition to the repeated packet originally allocated for the PDSCH and retransmit the PDSCH, so the UE may successfully decode the transport block.

For example, a NACK message with two bits may use the two bits to indicate whether the UE is again required or desired one, two, four, or eight repetitions to retransmit the PDSCH. For example, in some embodiments, if the two bits are 00, the UE expects one repetition during retransmission of PDSCH; if the two bits are 01, the UE expects two more repetitions during retransmission of PDSCH; if the two bits are 10, the UE expects four more repetitions during retransmission of PDSCH; and if the two bits are 11, the UE expects eight more repetitions during retransmission of PDSCH. In some embodiments, the bits may be mapped to different repetition values. In some embodiments, additional bits may be used.

Additionally, in some embodiments, the bits may also or alternatively be used to indicate a desired Redundancy Version (RV) sequence and MCS Modulation and Coding Scheme (MCS). The additional information provided by these bits may come at the cost of a more complex and larger Uplink Control Information (UCI) payload, but may provide valuable information to the gNB.

In some embodiments, PUCCH resources a and B may be the same, meaning that the gNB may need to experience different UCI payload hypotheses instead of different PUCCH resources. For example, rather than transmitting an ACK message on resource a and a NACK message on resource b, the ACK message may be associated with a first hypothesis and the NACK message may be associated with a second hypothesis.

Fig. 3 is a flowchart of a method 300 for a UE to indicate a desired number of repetitions of a PDSCH according to a second embodiment. In this embodiment, the UE generates a soft ACK/NACK report that is multi-bit for both ACK and NACK messages. In other words, both ACKs and NACKs are mapped to one or more code points (i.e., bit sequences). In this embodiment, a single PUCCH resource is used and the gNB need not experience different assumptions.

For PDSCH repetition, a UE using method 300 may provide soft ACK/NACK reporting instead of single bit ACK/NACKs for repeated packets. The soft ACK/NACK report may allow the UE to provide more information to the gNB as to whether the number of allocated repetitions is sufficient, redundant, or insufficient, and how many repetitions the UE needs or expects again.

In the illustrated embodiment, the UE receives PDSCH repeated packets 302 from the gNB. The UE may attempt to decode the transport block 304 within the PDSCH repeated packet. The UE may prepare a soft ACK/NACK report to inform the gNB whether the UE is able to successfully decode the transport block 306 or whether the UE needs the gNB to retransmit the PDSCH. In addition, the soft ACK/NACK report may include additional information indicating whether the number of repetitions of the PDSCH is sufficient, redundant, or insufficient, and how many repetitions the UE needs or desires again.

The UE may generate a soft ACK/NACK report 308 with a multi-bit ACK message or NACK message based on decoding success. For example, if the UE is able to successfully decode the transport block 306, the UE may generate a soft ACK/NACK report 308 with a multi-bit ACK message. If the UE fails to decode the transport block, the UE may generate 308 and send a soft ACK/NACK report with a multi-bit NACK message. In some embodiments, the bits may be mapped to different code points that indicate the additional number of repetitions that the UE expects to successfully decode the transport block. The gNB receiving the soft ACK/NACK report may add additional repetition to the repeated packet originally allocated for the PDSCH and retransmit the PDSCH, so the UE may successfully decode the transport block.

For example, the soft ACK/NACK report may include two bits. In some embodiments, if the two bits are 00, the bits correspond to a NACK indicating that the UE expects eight more repetitions during retransmission of PDSCH; if the two bits are 01, the bits correspond to a NACK indicating that the UE expects four more repetitions during retransmission of the PDSCH; if the two bits are 10, the bits correspond to a NACK indicating that the UE expects two more repetitions during retransmission of PDSCH; and if the two bits are 11, the bits correspond to an ACK indicating that the transport block was successfully decoded. In some embodiments, the bits may be mapped to different repetition values.

In some embodiments, additional bits may be used. With more bits, the ACK may be mapped to different states, each of which may indicate that the number of additional repetitions originally allocated is too large, and also indicate how many repetitions are additional repetitions and where decoding the transport block is not needed. For example, the bits may include a code point that may indicate to the gNB that the UE only decodes the transport block 2 times repeatedly.

Fig. 4 is a flowchart of a method 400 for a gNB to determine a desired number of repetitions of a PDSCH, according to one embodiment. As shown, the gNB may transmit PDSCH repeated packets 402 to the UE. The UE may transmit a soft ACK/NACK report based on whether the UE is able to decode the transport block of the PDSCH.

The gNB receives the soft ACK/NACK report 404 and decodes the soft ACK/NACK report 406. As described with reference to fig. 2 and 3, the soft ACK/NACK report may indicate whether the number of allocated repetitions is sufficient, redundant or insufficient, and how many repetitions the UE needs or desires again. The gNB may use this information from the soft ACK/NACK report to determine whether to keep the number of repetitions, increase the number of repetitions, or decrease the number of repetitions 408 for future transmissions of the PDSCH. For example, if there is a NACK 410 in the soft ACK/NACK report, the gNB retransmits the PDSCH 412 with the additional number of repetitions indicated in the soft ACK/NACK report.

Fig. 5 illustrates a flowchart of a method 500 for a UE to indicate a desired increase in the number of symbols (N1) between the end of PDSCH transmission and the start of PUCCH transmission, according to one embodiment. N1 represents the number of symbols between the end of PDSCH and the start of PUCCH transmission. The number N1 depends on the minimum subcarrier spacing (SCS) between PDCCH, PDSCH and PUCCH (min (μ_pdcch, μ_pdsch, μ_ul)) and also depends on UE capability. Based on UE capability, the soft ACK/NACK report may indicate an increase of N1, e.g., n1+d, where d > =0. The purpose of the extra d is to ensure that the UE has enough time to perform the required processing.

As shown, the UE may receive PDSCH repeated packets from the gNB 502 and determine if there is sufficient time to perform this process 504. If there is not enough time, the UE may generate a soft ACK/NACK report to indicate the desired increase 506 to N1. In some embodiments, to report UE capabilities, the UE may report N1 only, d may be fixed in the specification (e.g., d is preprogrammed to be equal to 1 or 2 symbols). In some embodiments, the UE reports N1 and d together (i.e., n1+d).

In some implementations, several factors may influence the d-value determination. For example, handling soft A/N bits in a soft ACK/NACK report may affect the d value. In some embodiments, the repetition number estimation may affect the d-value determination. The repetition number estimate is based on a process of determining an effective signal to interference plus noise ratio (SINR) from the current reception and a mapping estimate of the repetition needed to fill the gap between the effective SINR and the desired SINR. The gNB receiving the soft ACK/NACK report indicating an increase of N1 may thus increase the number of symbols between the end of PDSCH and the start of PUCCH transmission.

Exemplary System architecture

In certain embodiments, the 5G system architecture supports data connectivity and services enabling deployment to use technologies such as network function virtualization and software defined networking. The 5G system architecture may utilize service-based interactions between control plane network functions. Separating user plane functions from control plane functions allows for independent scalability, evolution, and flexible deployment (e.g., centralized locations or distributed (remote) locations). The modular function design allows for functionality reuse and enables flexible and efficient network slicing. The network function and its network function services may interact with another NF and its network function services directly or indirectly via a service communication proxy. Another intermediate function may assist in routing control plane messages. The architecture minimizes the dependency between AN and CN. The architecture may include AN aggregated core network with a common AN-CN interface integrating different access types (e.g., 3GPP access and non-3 GPP access). The architecture may also support a unified authentication framework, stateless NF with computing resources decoupled from storage resources, capability exposure, concurrent access to local and centralized services (to support low latency services and access to local data networks, user plane functions may be deployed near the AN), and/or roaming with both home routing traffic and local breakout traffic in the visited PLMN.

The 5G architecture may be defined as service-based and interactions between network functions may include service-based representations in which network functions (e.g., AMFs) within the control plane enable other authorized network functions to access their services. The service-based representation may also include a point-to-point reference point. The reference point representation may also be used to illustrate interactions between NF services in a network function described by a point-to-point reference point (e.g., N11) between any two network functions (e.g., AMF and SMF).

Fig. 6 illustrates a service-based architecture 600 in 5GS according to one embodiment. As described in 3gpp TS 23.501, service-based architecture 600 includes NFs, such as NSSF 608, NEF 610, NRF 614, PCF 612, UDM 626, AUSF 618, AMF 620, SMF 622, to communicate with UEs 616, (R) AN 606, UPF 602, and DN 604. NF and NF services may communicate directly (referred to as direct communication) or indirectly via the SCP 624 (referred to as indirect communication). Fig. 6 also shows corresponding service-based interfaces including Nutm, naf, nudm, npcf, nsmf, nnrf, namf, nnef, nnssf and Nausf and reference points N1, N2, N3, N4 and N6. Some exemplary functions provided by the NF shown in fig. 6 are described below.

NSSF 608 supports functions such as: selecting a set of network slice instances serving the UE; determining allowed NSSAI and, if necessary, mapping to subscribed S-NSSAI; determining the configured NSSAI and, if necessary, the mapping to subscribed S-NSSAI; and/or determining a set of AMFs to be used for serving the UE, or determining a list of candidate AMFs by querying the NRF based on the configuration.

NEF 610 supports the exposure of capabilities and events. NF capabilities and events may be safely exposed by NEF 610 (e.g., for third parties, application functions, and/or edge computing). The NEF 610 may store/retrieve information as structured data using a standardized interface (Nudr) to UDR. The NEF 610 may also securely provide information from external applications to the 3GPP network and may provide application functions to securely provide information (e.g., expected UE behavior, 5GLAN group information, and service specific information) to the 3GPP network, where the NEF 610 may authenticate and authorize and help limit application functions. The NEF 610 may provide for the conversion of internal-external information by converting between information exchanged with the AF and information exchanged with internal network functions. For example, NEF 610 translates between AF service identifiers and internal 5G core information (such as DNN and S-NSSAI). The NEF 610 may handle masking of network and user sensitive information of external AFs according to network policies. The NEF 610 may receive information from other network functions (based on the exposed capabilities of the other network functions) and store the received information as structured data using a standardized interface to the UDR. The stored information may be accessed by NEF 610 and re-exposed to other network functions and application functions, and used for other purposes such as analysis. For external exposure of services associated with a particular UE, the NEF 610 may reside in the HPLMN. According to the operator protocol, the NEF 610 in the HPLMN may have an interface with the NF in the VPLMN. Scef+nef may be used for service exposure when the UE is able to switch between EPC and 5 GC.

NRF 614 supports service discovery functions by receiving NF discovery requests from NF instances or SCPs and providing information of the discovered NF instances to the NF instances or SCPs. NRF 614 may also support P-CSCF discovery (a special case of SMF discovery AF), keep NF profiles of available NF instances and services supported by them, and/or notify subscribed NF service consumers or SCPs of newly registered/updated/unregistered NF instances along with their NF services. In the context of network slicing, multiple NRFs may be deployed at different levels based on network implementation, such as PLMN level (NRF configured with information of the entire PLMN), shared slice level (NRF configured with information belonging to the set of network slices), and/or slice specific level (NRF configured with information belonging to the S-NSSAI). In the context of roaming, multiple NRFs may be deployed in different networks, wherein NRFs in a visited PLMN (referred to as vNRF) are configured with information of the visited PLMN, and wherein NRFs in a home PLMN (referred to as hNRF) are configured with information of the home PLMN, referenced by the vNRF via an N27 interface.

PCF 612 supports a unified policy framework to govern network behavior. PCF 612 provides policy rules for control plane functions to implement them. PCF 612 accesses subscription information related to policy decisions in a Unified Data Repository (UDR). PCF 612 may access a UDR located in the same PLMN as the PCF.

The UDM 626 supports generation of 3GPP AKA authentication credentials, user identification processing (e.g., storage and management of SUPI for each user in a 5G system), unhidden of privacy protection subscription identifiers (sui), access authorization based on subscription data (e.g., roaming restrictions), service NF registration management of UEs (e.g., storing service AMFs for UEs, storing service SMFs for PDU sessions of UEs), service/session continuity (e.g., by maintaining SMF/DNN allocations for ongoing sessions), MT-SMS delivery, lawful interception functions (especially in case of outbound roaming where UDM is the sole point of contact of LI), subscription management, SMS management, 5GLAN group management processing, and/or external parameter configuration (expected UE behavior parameters or network configuration parameters). To provide such functionality, the UDM 626 uses subscription data (including authentication data) that may be stored in the UDR, in which case the UDM implements application logic and may not require internal user data storage, and several different UDMs may serve the same user in different transactions. The UDM 626 may be located in the HPLMN of the user it serves and may access information of UDRs located in the same PLMN.

The AF 628 interacts with the core network to provide services that support, for example: influence of application program on traffic route; accessing the NEF 610; interacting with a policy framework for policy control; and/or interaction of IMS with 5 GC. Based on the operator deployment, application functions that are considered trusted by the operator may be allowed to interact directly with related network functions. Application functions that the operator does not allow direct access to network functions may interact with related network functions using the external exposure framework via the NEF 610.

AUSF 618 supports authentication for 3GPP access and untrusted non-3 GPP access. AUSF 618 may also provide support for network slice specific authentication and authorization.

The AMF 620 supports termination of RAN CP interface (N2), termination of NAS (N1) for NAS ciphering and integrity protection, registration management, connection management, reachability management, mobility management, lawful interception (for AMF events and interfaces to LI systems), transfer of SM messages between UE and SMF, transparent proxy for routing SM messages, access authentication, access authorization, transfer of SMs messages between UE and SMSF, SEAF, location service management for policing services, transfer of location service messages between UE and LMF and between RAN and LMF, EPS bearer ID allocation for interworking with EPS, UE mobility event notification, control plane CIoT 5GS optimization, user plane CIoT 5GS optimization, configuration external parameters (expected UE behavior parameters or network configuration parameters) and/or network slice specific authentication and authorization. Some or all of the AMF functions may be supported in a single instance of AMF 620. Regardless of the number of network functions, in some embodiments, only one NAS interface instance per access network between UE and CN terminates in one of the network functions that implements at least NAS security and mobility management. AMF 620 may also include policy related functions.

In addition to the above functions, AMF 620 may include the following functions to support non-3 GPP access networks: supporting an N2 interface with N3 IWF/tnff, over which some information (e.g., 3GPP cell identity) and procedures (e.g., handover related) defined on the 3GPP access may not be applicable and non-3 GPP access specific information not applicable to the 3GPP access may be applicable; supporting NAS signaling with UEs over N3 IWF/tnff, where some procedures supported by NAS signaling over 3GPP access may not be applicable for untrusted non-3 GPP (e.g., paging) access; authentication of a UE supporting connection over N3 IWF/TNGF; management of mobility, authentication and individual security context states for UEs connected via a non-3 GPP access connection or simultaneously via a 3GPP access or a non-3 GPP access connection; supporting an efficient coordinated RM management context over 3GPP access and non-3 GPP access; and/or support dedicated CM management contexts for UE connection through non-3 GPP access. It may not be necessary to support all of the above functions in the example of network slicing.

SMF 622 supports session management (e.g., session establishment, modification and release, including tunnel maintenance between UPF and AN nodes), UE IP address assignment and management (including optional authorization), where UE IP addresses may be received from the UPF or from AN external data network, DHCPv4 (server and client) and DHCPv6 (server and client) functions, functions that respond to address resolution protocol requests and/or IPv6 neighbor solicitation requests based on local cache information of ethernet PDUs (e.g., the SMF responds to ARP and/or IPv6 neighbor solicitation requests by providing a MAC address corresponding to the IP address transmitted in the request), selection and control of user plane functions (including controlling the UPF to proxy ARP or IPv6 neighbor discovery or forward all ARP/IPv6 neighbor solicitation traffic to the SMF for ethernet PDU sessions), traffic steering configuration at the UPF routes traffic to the appropriate destination, 5G VN group management (e.g. maintaining the topology of the involved PSA, AN N19 tunnel is established and published between the PSA UPFs, traffic forwarding is configured at the UPFs to apply local switching, and/or N6-based forwarding or N19-based forwarding), terminating AN interface towards policy control functions, lawful interception (for SM events and interfaces to LI systems), charging for data collection and supporting charging interfaces, controlling and coordinating charging data collection at UPF, terminating SM part of NAS message, downlink data notification, initiator of AN specific SM information transmitted via AMF through N2 to AN, determination of SSC mode of session, control plane CIoT 5GS optimization, header compression, some or all of the SMF functions may be supported in a single instance of the SMF, however, in some embodiments not all of the functions need to be supported in instances of network slicing, in addition to these functions, the SMF 622 may also include policy-related functions.

The SCP 624 includes one or more of the following functions: indirect communication; delegated discovery; message forwarding and routing to destination NF/NF services; communication security (e.g., authorization of NF service consumers to access NF service manufacturer APIs), load balancing, monitoring, overload control, etc.; and/or optionally interact with UDR to resolve UDM group ID/UDR group ID/AUSF group ID/PCF group ID/CHF group ID/HSS group ID based on UE identity (e.g., SUPI or IMPI/IMPU). Some or all of the SCP functions may be supported in a single instance of the SCP. In some embodiments, the SCPs 624 may be deployed in a distributed manner and/or more than one SCP may be present in the communication path between NF services. SCP can be deployed at PLMN level, shared slice level, and slice specific level. Operator deployments may be left to ensure that the SCP can communicate with the relevant NRF.

UE 616 may include devices with radio communication capabilities. For example, the UE 616 may include a smart phone (e.g., a handheld touch screen mobile computing device capable of connecting to one or more cellular networks). UE 616 may also include any mobile or non-mobile computing device, such as a Personal Data Assistant (PDA), pager, laptop computer, desktop computer, wireless handheld device, or any computing device that includes a wireless communication interface. A UE is also known as a client, mobile phone, mobile device, mobile terminal, user terminal, mobile unit, mobile station, mobile user, subscriber, user, remote station, access agent, user agent, receiver, radio equipment, reconfigurable radio equipment, or reconfigurable mobile device. UE 616 may include an IoT UE that may include a network access layer designed for low power IoT applications that utilize short-term UE connections. IoT UEs may utilize technologies (e.g., M2M, MTC or mctc technologies) to exchange data with MTC servers or devices via PLMNs, other UEs using ProSe or D2D communications, sensor networks, or IoT networks. The M2M or MTC data exchange may be a machine-initiated data exchange. IoT networks describe interconnected IoT UEs that may include uniquely identifiable embedded computing devices (within the internet infrastructure). The IoT UE may execute a background application (e.g., keep-alive messages, status updates, etc.) to facilitate connection of the IoT network.

UE 616 may be configured to connect or communicatively couple with (R) AN 606 over a radio interface 630, which may be a physical communication interface or layer configured to operate with a cellular communication protocol such as a GSM protocol, a CDMA network protocol, a push-to-talk (PTT) protocol, a PTT Over Cellular (POC) protocol, a UMTS protocol, a 3GPP LTE protocol, a 5G protocol, AN NR protocol, and the like. For example, the UE 616 and the (R) AN 606 may use a Uu interface (e.g., AN LTE-Uu interface) to exchange control plane data via a protocol stack including a PHY layer, a MAC layer, AN RLC layer, a PDCP layer, and AN RRC layer. DL transmissions may be from the (R) AN 606 to the UE 616, and UL transmissions may be from the UE 616 to the (R) AN 606.UE 616 may also communicate directly with another UE (not shown) using a side link for D2D, P2P and/or ProSe communications. For example, the ProSe interface may include one or more logical channels including, but not limited to, a physical side link control channel (PSCCH), a physical side link shared channel (PSSCH), a physical side link discovery channel (PSDCH), and a physical side link broadcast channel (PSBCH).

The (R) AN 606 may include one or more access nodes, which may be referred to as Base Stations (BS), nodebs, evolved nodebs (enbs), next generation nodebs (gnbs), RAN nodes, controllers, transmission and Reception Points (TRPs), etc., and may include ground stations (e.g., terrestrial access points) or satellite stations that provide coverage within a geographic area (e.g., cell). The (R) AN 606 may include one or more RAN nodes for providing a macrocell, a picocell, a femtocell, or other type of cell. A macrocell may cover a relatively large geographic area (e.g., several kilometers in radius) and may allow unrestricted access by UEs with service subscriptions. The pico cell may cover a relatively small geographic area and may allow unrestricted access by UEs with service subscription. A femto cell may cover a relatively small geographic area (e.g., a home) and may allow limited access to UEs that have an association with the femto cell (e.g., UEs in a Closed Subscriber Group (CSG), UEs of users in the home, etc.).

Although not shown, multiple RAN nodes, such as (R) AN 606, may be used, with AN Xn interface defined between two or more nodes. In some implementations, the Xn interface can include an Xn user plane (Xn-U) interface and an Xn control plane (Xn-C) interface. Xn-U may provide non-guaranteed delivery of user plane PDUs and support/provide data forwarding and flow control functions. An Xn-C may provide management and error handling functions for managing the functions of the Xn-C interface; mobility support for UE 616 in CONNECTED mode (e.g., CM-CONNECTED) includes functionality for managing UE mobility in CONNECTED mode between one or more (R) AN nodes. The mobility support may include a context transfer from AN old (source) service (R) AN node to a new (target) service (R) AN node; and control of user plane tunnels between old (source) serving (R) AN nodes to new (target) serving (R) AN nodes.

UPF 602 may act as an anchor point for intra-RAT and inter-RAT mobility, an external PDU session point interconnected with DN 604, and a branching point to support multi-homed PDU sessions. The UPF 602 may also perform packet routing and forwarding, packet inspection, user plane part of enforcing policy rules, lawful interception packets (UP collection); traffic usage reporting, performing QoS processing (e.g., packet filtering, gating, UL/DL rate execution) on the user plane, performing uplink traffic verification (e.g., SDF to QoS flow mapping), transmission level packet marking in uplink and downlink, and downlink packet buffering and downlink data notification triggering. UPF 602 may include an uplink classifier to support routing traffic flows to a data network. DN 604 may represent various network operator services, internet access, or third party services. DN 604 can include, for example, an application server.

Fig. 7 is a block diagram of a configurable example UE 700, including by executing instructions corresponding to any of the example methods and/or processes described herein on a computer-readable medium, according to various embodiments of the present disclosure. The UE 700 includes one or more processors 702, a transceiver 704, memory 706, a user interface 708, and a control interface 710.

The one or more processors 702 may include, for example, an application processor, an audio digital signal processor, a central processing unit, and/or one or more baseband processors. Each of the one or more processors 702 may include internal memory and/or may include an interface for communicating with external memory (including memory 706). The internal or external memory may store software code, programs, and/or instructions for execution by the one or more processors 702 to configure and/or facilitate the UE 700 to perform various operations, including the operations described herein. For example, execution of the instructions may configure the UE 700 to communicate using one or more wired or wireless communication protocols (including one or more wireless communication protocols standardized by 3GPP, such as those commonly referred to as 5G/NR, LTE, LTE-A, UMTS, HSPA, GSM, GPRS, EDGE, etc.) or any other current or future protocols that may be used in conjunction with the one or more transceivers 704, user interface 708, and/or control interface 710. As another example, the one or more processors 702 can execute program code stored in the memory 706 or other memory corresponding to MAC, RLC, PDCP and RRC layer protocols standardized by 3GPP (e.g., for NR and/or LTE). As another example, the processor 702 may execute program code stored in the memory 706 or other memory that, in conjunction with the one or more transceivers 704, implements corresponding PHY layer protocols, such as Orthogonal Frequency Division Multiplexing (OFDM), orthogonal Frequency Division Multiple Access (OFDMA), and single carrier frequency division multiple access (SC-FDMA).

The memory 706 may include a memory area for the one or more processors 702 to store variables used in the protocols, configurations, controls, and other functions of the UE 700, including operations corresponding to or including any of the example methods and/or processes described herein. Further, the memory 706 may include non-volatile memory (e.g., flash memory), volatile memory (e.g., static or dynamic RAM), or a combination thereof. Further, the memory 706 may interact with memory slots through which one or more formats of removable memory cards (e.g., SD cards, memory sticks, compact flash, etc.) may be inserted and removed.

The one or more transceivers 704 may include radio frequency transmitter and/or receiver circuitry that facilitates communication of the UE 700 with other equipment supporting similar wireless communication standards and/or protocols. For example, the one or more transceivers 704 may include switches, mixer circuits, amplifier circuits, filter circuits, and synthesizer circuits. Such RF circuitry may include a receive signal path having circuitry to down-convert an RF signal received from a Front End Module (FEM) and provide a baseband signal to a baseband processor of the one or more processors 702. The RF circuitry may also include a transmit signal path that may include circuitry for up-converting the baseband signal provided by the baseband processor and providing an RF output signal for transmission to the FEM. The FEM may include a receive signal path that may include circuitry configured to operate on RF signals received from one or more antennas, amplify the receive signal, and provide an amplified version of the receive signal to the RF circuitry for further processing. The FEM may also include a transmit signal path that may include circuitry configured to amplify a transmit signal provided by the RF circuitry for transmission by the one or more antennas. In various implementations, amplification through the transmit or receive signal path may be accomplished in the RF circuit alone, in the FEM alone, or in both the RF circuit and FEM circuit. In some implementations, the FEM circuitry may include TX/RX switches to switch between transmit and receive mode operation.

In some demonstrative embodiments, the one or more transceivers 704 include a transmitter and a receiver to enable device 1200 to communicate with various 5G/NR networks in accordance with various protocols and/or methods proposed for standardization by 3GPP and/or other standards bodies. For example, such functionality may operate in cooperation with the one or more processors 702 to implement a PHY layer based on OFDM, OFDMA, and/or SC-FDMA techniques, such as described herein with reference to other figures.

The user interface 708 may take various forms depending on the particular implementation, or may not be present in the UE 700. In some implementations, the user interface 708 includes a microphone, speaker, slidable button, depressible button, display, touch screen display, mechanical or virtual keypad, mechanical or virtual keyboard, and/or any other user interface features typically found on mobile phones. In other embodiments, the UE 700 may comprise a tablet computing device with a larger touch screen display. In such implementations, one or more of the mechanical features of the user interface 708 may be replaced with equivalent or functionally equivalent virtual user interface features (e.g., virtual keypads, virtual buttons, etc.) implemented using a touch screen display, as would be familiar to one of ordinary skill in the art. In other embodiments, the UE 700 may be a digital computing device, such as a laptop computer, desktop computer, workstation, etc., that includes a mechanical keyboard that may be integrated, detached, or detachable in accordance with certain exemplary embodiments. Such digital computing devices may also include a touch screen display. Many exemplary embodiments of the UE 700 with a touch screen display are capable of receiving user input, such as input related to exemplary methods and/or processes described herein or known to those of ordinary skill in the art.

In some example embodiments of the present disclosure, the UE 700 includes an orientation sensor that may be used by features and functions of the UE 700 in various ways. For example, the UE 700 may use the output of the orientation sensor to determine when the user has changed the physical orientation of the touch screen display of the UE 700. The indication signal from the orientation sensor may be used for any application executing on the UE 700 such that the application may automatically change the orientation of the screen display (e.g., from portrait to landscape) upon an approximately 90 degree change in the physical orientation of the indication signal indicating device. In this way, the application can maintain the screen display in a user-readable manner regardless of the physical orientation of the device. In addition, the output of the orientation sensor may be used in connection with various exemplary embodiments of the present disclosure.

Control interface 710 may take various forms depending on the particular implementation. For example, control interface 710 may include an RS-232 interface, an RS-485 interface, a USB interface, an HDMI interface, a Bluetooth interface, an IEEE ("firewire") interface, I ² C interface, PCMCIA interface, etc. In some exemplary embodiments of the present disclosure, the control interface 1260 may comprise an IEEE 802.3 ethernet interface, such as described above. In some embodiments of the present disclosure, control interface 710 may include analog interface circuitry including, for example, one or more digital-to-analog (D/a) converters and/or analog-to-digital (a/D) converters.

Those of ordinary skill in the art will recognize that the above list of features, interfaces, and radio frequency communication standards is exemplary only and is not limiting to the scope of the present disclosure. In other words, the UE 700 may include more functionality than shown in fig. 7, including, for example, a video and/or still image camera, microphone, media player and/or recorder, and the like. In addition, the one or more transceivers 704 may include circuitry for communicating using additional radio frequency communication standards including Bluetooth, GPS, and/or others. Further, the one or more processors 702 may execute software code stored in the memory 706 to control such additional functions. For example, the directional velocity and/or position estimate output from the GPS receiver may be used by any application executing on the UE 700, including various exemplary methods and/or computer readable media according to various exemplary embodiments of the present disclosure.

Fig. 8 is a block diagram of a configurable example network node 800, including by executing instructions corresponding to any of the example methods and/or processes described herein on a computer-readable medium, according to various embodiments of the present disclosure.

The network node 800 comprises one or more processors 802, a radio network interface 804, memory 806, a core network interface 808, and other interfaces 810. The network node 800 may comprise, for example, a base station, an eNB, a gNB, an access node, or a component thereof.

The one or more processors 802 may include any type of processor or processing circuit and may be configured to perform one of the methods or processes disclosed herein. The memory 806 may store software code, programs, and/or instructions that are executed by the one or more processors 802 to configure the network node 800 to perform various operations, including the operations described herein. For example, execution of such stored instructions may configure network node 800 to communicate with one or more other devices using protocols (including one or more of the methods and/or processes discussed above) according to various embodiments of the present disclosure. Moreover, execution of such stored instructions may also configure and/or facilitate network node 800 to communicate with one or more other devices using other protocols or protocol layers (such as one or more of PHY, MAC, RLC, PDCP and RRC layer protocols standardized by 3GPP for LTE, LTE-a, and/or NR, or any other higher layer protocols used in conjunction with radio network interface 804 and core network interface 808). By way of example and not limitation, the core network interface 808 includes an S1 interface and the radio network interface 804 may include a Uu interface as standardized by 3 GPP. The memory 806 may also store variables used in protocols, configurations, controls, and other functions of the network node 800. Thus, the memory 806 may include non-volatile memory (e.g., flash memory, hard disk, etc.), volatile memory (e.g., static or dynamic RAM), network-based (e.g., "cloud") storage, or a combination thereof.

The radio network interface 804 may include transmitters, receivers, signal processors, ASICs, antennas, beam forming units, and other circuitry that enables the network node 800 to communicate with other equipment, such as multiple compatible User Equipment (UEs), in some embodiments. In some embodiments, the network node 800 may include various protocols or protocol layers, such as PHY, MAC, RLC, PDCP and RRC layer protocols standardized by 3GPP for LTE, LTE-a, and/or 5G/NR. According to further embodiments of the present disclosure, the radio network interface 804 may include a PHY layer based on OFDM, OFDMA, and/or SC-FDMA techniques. In some embodiments, the functionality of such PHY layers may be cooperatively provided by the radio network interface 804 and the one or more processors 802.

The core network interface 808 may include a transmitter, a receiver, and other circuitry that enables the network node 800 to communicate with other equipment in a core network, such as a Circuit Switched (CS) and/or packet switched core (PS) network in some embodiments. In some embodiments, the core network interface 808 may include an S1 interface standardized by 3 GPP. In some embodiments, the core network interface 808 may include one or more interfaces to one or more SGW, MME, SGSN, GGSN and other physical devices that include functionality known to those of ordinary skill in the art as present in GERAN, UTRAN, E-UTRAN and CDMA2000 core networks. In some embodiments, these one or more interfaces may be multiplexed together on a single physical interface. In some implementations, the lower layers of the core network interface 808 may include one or more of Asynchronous Transfer Mode (ATM), internet protocol over ethernet (IP), SDH over fiber, T1/E1/PDH over copper wire, microwave radio, or other wired or wireless transmission techniques known to those of ordinary skill in the art.

Other interfaces 810 may include transmitters, receivers, and other circuitry enabling network node 800 to communicate with external networks, computers, databases, etc. for operating, managing, and maintaining network node 800 or other network devices operatively connected thereto.

For one or more embodiments, at least one of the components shown in one or more of the foregoing figures may be configured to perform one or more operations, techniques, procedures, and/or methods described in the examples section below. For example, the baseband circuitry described above in connection with one or more of the foregoing figures may be configured to operate according to one or more of the following examples. As another example, circuitry associated with a UE, base station, network element, etc. described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples shown in the examples section below.

Examples section

The following examples relate to further embodiments.

Embodiment 1 may comprise an apparatus comprising means for performing one or more elements of the methods described herein or any one of the processes described herein or related thereto.

Embodiment 2 may include one or more non-transitory computer-readable media comprising instructions that, when executed by one or more processors of an electronic device, cause the electronic device to perform one or more elements of the method or any other method or process described in or related to any of the above embodiments.

Embodiment 3 may comprise an apparatus comprising logic, modules, or circuitry to perform one or more elements of the method described in or associated with any of the embodiments described above or any other method or process described herein.

Embodiment 4 may include a method, technique, or process, or portion or part thereof, as described in or associated with any of the embodiments above.

Embodiment 5 may include an apparatus comprising: one or more processors and one or more computer-readable media comprising instructions that, when executed by the one or more processors, cause the one or more processors to perform the method, technique, or process, or portion thereof, as described in or related to any of the above embodiments.

Embodiment 6 may include a signal or portion or part thereof as described in or associated with any of the embodiments above.

Embodiment 7 may include a datagram, packet, frame, segment, protocol Data Unit (PDU) or message, or portion or part thereof, as described in or associated with any of the above embodiments, or otherwise described in this disclosure.

Embodiment 8 may include a data-encoded signal or portion or component thereof as described in or relating to any of the above embodiments or otherwise described in this disclosure.

Embodiment 9 may include a signal encoded with a datagram, packet, frame, segment, PDU, or message, or portion or feature thereof, as described in any of the above embodiments or otherwise described in this disclosure.

Embodiment 10 may comprise an electromagnetic signal bearing computer-readable instructions that, when executed by one or more processors, cause the one or more processors to perform the method, technique, or process, or portion thereof, of or associated with any of the embodiments described above.

Embodiment 11 may include a computer program comprising instructions, wherein execution of the program by a processing element will cause the processing element to perform a method, technique or process or part thereof as described in or in connection with any one of the embodiments above.

Embodiment 12 may include signals in a wireless network as shown and described herein.

Embodiment 13 may include a method of communicating in a wireless network as shown and described herein.

Embodiment 14 may include a system for providing wireless communications as shown and described herein.

Embodiment 15 may include an apparatus for providing wireless communications as shown and described herein.

Any of the above embodiments may be combined with any other embodiment (or combination of embodiments) unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of the embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various implementations.

Embodiments and implementations of the systems and methods described herein may include various operations that may be embodied in machine-executable instructions to be executed by a computer system. The computer system may include one or more general-purpose or special-purpose computers (or other electronic devices). The computer system may include hardware components that include specific logic components for performing operations, or may include a combination of hardware, software, and/or firmware.

It should be appreciated that the systems described herein include descriptions of specific embodiments. These embodiments may be combined into a single system, partially incorporated into other systems, divided into multiple systems, or otherwise divided or combined. Furthermore, it is contemplated that in another embodiment parameters, attributes, aspects, etc. of one embodiment may be used. For the sake of clarity, these parameters, attributes, aspects, etc. are described in one or more embodiments only, and it should be recognized that these parameters, attributes, aspects, etc. may be combined with or substituted for parameters, attributes, aspects, etc. of another embodiment unless specifically stated herein.

It is well known that the use of personally identifiable information should follow privacy policies and practices that are recognized as meeting or exceeding industry or government requirements for maintaining user privacy. In particular, personally identifiable information data should be managed and processed to minimize the risk of inadvertent or unauthorized access or use, and the nature of authorized use should be specified to the user.

Although the foregoing has been described in some detail for purposes of clarity of illustration, it will be apparent that certain changes and modifications may be practiced without departing from the principles of the invention. It should be noted that there are many alternative ways of implementing both the processes and apparatuses described herein. The present embodiments are, therefore, to be considered as illustrative and not restrictive, and the description is not to be limited to the details given herein, but may be modified within the scope and equivalents of the appended claims.

Claims (20)

1. A method for a User Equipment (UE), comprising:

receiving a Physical Downlink Shared Channel (PDSCH) repeated packet from a network node;

attempting to decode a transport block within the PDSCH repeated packet; and

a soft acknowledgement/negative acknowledgement (ACK/NACK) report is generated based on whether the transport block was successfully decoded,

wherein the soft ACK/NACK report includes an ACK message when the transport block is successfully decoded, and

wherein when the transport block is not successfully decoded, the soft ACK/NACK report includes a NACK message including a plurality of bits indicating a number of additional repetitions of the PDSCH required to successfully decode the transport block.

2. The method of claim 1, further comprising: and transmitting the soft ACK/NACK report to the network node.

3. The method of claim 2, wherein the ACK message is transmitted on PUCCH resource a and the NACK message is transmitted on PUCCH resource B.

4. The method of claim 3, wherein the ACK message is a single bit.

5. The method of claim 4, wherein the NACK message is two bits, wherein the two bits are used to indicate whether one, two, four, or eight repetitions are needed.

6. The method of claim 1, wherein the soft ACK/NACK report comprises a plurality of bits, wherein:

00 is the NACK message indicating that 8 more repetitions are needed;

01 is the NACK message indicating that 4 more repetitions are needed;

10 is the NACK message indicating that 2 more repetitions are required; and is also provided with

11 is the ACK message.

7. The method of claim 1, further comprising: the soft ACK/NACK capability is reported to indicate an increase in the number of symbols between the end of PDSCH transmission and the beginning of PUCCH transmission.

8. A non-transitory computer-readable storage medium comprising instructions that, when executed by a User Equipment (UE), cause the computer to:

receiving a Physical Downlink Shared Channel (PDSCH) repeated packet from a network node;

attempting to decode a transport block within the PDSCH repeated packet; and

a soft acknowledgement/negative acknowledgement (ACK/NACK) report is generated based on whether the transport block was successfully decoded,

wherein the soft ACK/NACK report includes an ACK message when the transport block is successfully decoded, and

wherein when the transport block is not successfully decoded, the ACK/NACK report includes a NACK message including a plurality of bits indicating a number of additional repetitions of the PDSCH required to successfully decode the transport block.

9. The computer-readable storage medium of claim 8, wherein the instructions further configure the computer to transmit the soft ACK/NACK report to the network node.

10. The computer-readable storage medium of claim 9, wherein the ACK message is transmitted on PUCCH resource a and the NACK message is transmitted on PUCCH resource B.

11. The computer-readable storage medium of claim 10, wherein the ACK message is a single bit.

12. The computer-readable storage medium of claim 11, wherein the NACK message is two bits, wherein the two bits are used to indicate whether one, two, four, or eight repetitions are needed.

13. The computer-readable storage medium of claim 8, wherein the soft ACK/NACK report comprises a plurality of bits, wherein:

00 is the NACK message indicating that 8 more repetitions are needed;

01 is the NACK message indicating that 4 more repetitions are needed;

10 is the NACK message indicating that 2 more repetitions are required; and is also provided with

11 is the ACK message.

14. The computer-readable storage medium of claim 8, the soft ACK/NACK report indicating an increase in a number of symbols between an end of PDSCH transmission and a start of PUCCH transmission.

15. A User Equipment (UE), the UE comprising:

a baseband processing unit; and

a memory storing instructions that, when executed by the baseband processing unit, cause the apparatus to:

receiving a Physical Downlink Shared Channel (PDSCH) repeated packet from a network node;

attempting to decode a transport block within the PDSCH repeated packet; and

a soft acknowledgement/negative acknowledgement (ACK/NACK) report is generated based on whether the transport block was successfully decoded,

wherein the soft ACK/NACK report includes an ACK message when the transport block is successfully decoded, and

wherein when the transport block is not successfully decoded, the ACK/NACK report includes a NACK message including a plurality of bits indicating a number of additional repetitions of the PDSCH required to successfully decode the transport block.

16. The UE of claim 15, further comprising: the ACK message is transmitted on PUCCH resource a and the NACK message is transmitted on PUCCH resource B.

17. The UE of claim 16, wherein the ACK message is a single bit.

18. The UE of claim 17, wherein the NACK message is two bits, wherein the two bits are used to indicate whether one, two, four, or eight repetitions are needed.

19. The UE of claim 15, wherein the soft ACK/NACK report comprises a plurality of bits, wherein:

00 is the NACK message indicating that 8 more repetitions are needed;

01 is the NACK message indicating that 4 more repetitions are needed;

10 is the NACK message indicating that 2 more repetitions are required; and is also provided with

11 is the ACK message.

20. The UE of claim 15, the soft ACK/NACK report indicating an increase in a number of symbols between an end of PDSCH transmission and a start of PUCCH transmission.

Images