Device for wireless communication

Abstract

The present disclosure relates to an apparatus. A device receives a first authorization for a resource from a network node connected to the device through a network, wherein the first authorization for the resource indicates a first lifetime associated with the first authorization, such that the first authorization is unusable when the first lifetime expires; selects a logical channel from among the plurality of logical channels of the device based on the lifetime associated with the first authorization; and sends data through the selected logical channel using the first authorization for the resource.

Description

[0001] This application is a divisional application of the patent application entitled “Device”, with international application number PCT / US2017 / 057483 and national application number 201780071969.X, filed on October 19, 2017.

[0002] Citation of Related Applications

[0003] This application claims the benefit of U.S. Provisional Patent Application Serial No. 62 / 410,049, filed on October 19, 2016, U.S. Provisional Patent Application Serial No. 62 / 501,397, filed on May 4, 2017, U.S. Provisional Patent Application Serial No. 62 / 545,747, filed on August 15, 2017, and U.S. Provisional Patent Application Serial No. 62 / 564,529, filed on September 28, 2017, the disclosures of which are incorporated herein by reference as if fully set forth herein. Background Art

[0004] The family of use cases for International Mobile Telecommunications (IMT) in 2020 and beyond includes: eMBB (enhanced mobile broadband), URLLC (ultra-reliable low latency communications) and mMTC (massive machine type communications). These major use cases have different and conflicting service requirements in terms of latency, data rate, mobility, device density, reliability, user equipment (UE) battery life, network energy consumption, etc. In view of these different and conflicting service requirements supported by the next generation of international mobile telecommunications systems, 3GPP has identified a set of system architecture requirements. However, it is recognized here that in order to meet these requirements, issues related to the UE and radio access network (RAN) data link model should be addressed, among other issues. Summary of the invention

[0005] Disclosed herein are new radio (NR) data link architecture options, including, for example, NR radio bearer models, NR logical channel models, and MAC and HARQ models. Also described are packet flow mappings to data radio bearers (DRBs), and a new flow encapsulation protocol in the user plane. In some embodiments, DRBs with different qualities of service (QoS) are pre-established but not activated. This allows a given user equipment (UE) to use these DRBs for packet data network (PDN) flows without significant overhead. Pre-established DRBs can be an extension of the default bearer concept where the pre-establishment of DRBs is determined based on UE capabilities, subscription profiles, operating policies, installed apps, etc.

[0006] According to another aspect disclosed herein, a given UE may prioritize network slices, physical layer (PHY) parameter sets, and logical channels for resource allocation based on a grant granted by the network to the UE. In addition, the UE may provide feedback to assist the network in allocating resource grants. For example, the feedback may include a new buffer status reporting option, a new power headroom reporting option, and a new scheduling request option.

[0007] In an example, a device, such as a UE, receives a grant of resources from a network node connected to the device through a network, wherein the grant of resources specifies how data from one or more nodes can be sent in an uplink in the network. The device allocates the grant of resources within the network. For example, the device may allocate the grant of resources to the multiple network slices according to a predetermined priority of the multiple network slices of the network. The device may allocate the grant of resources to the multiple network slices according to a slice priority bit rate associated with each of the multiple network slices of the network. In some cases, the grant of resources is shared by multiple physical layer parameter sets, so that more than one physical layer parameter set in the multiple physical layer parameter sets may be mapped to the same grant of resources. Here, the device may allocate the grant of resources to the multiple physical layer parameter sets according to a predetermined parameter set priority of the multiple physical layer parameter sets. The predetermined parameter set priority may be a function of a transmission time interval (TTI) configured for a service mapped to the corresponding parameter set. In an example, the device allocates the grant of resources to one of the multiple network slices. The device may also allocate the grant of resources to the physical layer parameter set indicated in the grant, so that the physical layer parameter set is the only physical layer parameter set to which the resource is allocated. Alternatively or additionally, the device may allocate the grant of resources to a specific logical channel indicated in the grant, such that the specific logical channel is the only logical channel to which resources are allocated. The grant of resources may indicate a physical resource block defined by time domain, frequency domain, modulation and coding scheme, and redundancy version information. The grant of resources may also include power control information for uplink transmissions, and indications or resources for uplink ACK / NACK transmissions.

[0008] This summary is provided to simplify some concepts further described in the detailed description below. This summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter. In addition, the claimed subject matter is not limited to solve any or all defects mentioned in any part of this disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] A more detailed understanding may be obtained from the following description given by way of example in conjunction with the accompanying drawings, in which:

[0010] Figure 1A , Figure 1B and Figure 1C The diagram illustrates different aspects of a packet data unit (PDU) session.

[0011] Figure 2 is a diagram illustrating an architecture for decoupling and independent evolution of an access network (AN) and a core network (CN).

[0012] Figure 3 is a diagram illustrating an example of centralized deployment.

[0013] Figure 4 is a diagram illustrating example functionality split between central and distributed units.

[0014] Figure 5 is a diagram illustrating split bearer by a master cell group (MCG).

[0015] Figure 6 is a diagram illustrating split bearer by a secondary cell group (SCG).

[0016] Figure 7 is a diagram illustrating secondary cell group bearing.

[0017] Figure 8 and Fig. 9 is a diagram illustrating an example of the use of network slicing.

[0018] Fig.10 is a diagram illustrating an example quality of service (QoS) functional partitioning.

[0019] Fig.11 is a diagram illustrating the relationship of service data flows, packet flows, service data flow templates, and service data flow filters.

[0020] Fig.12 is a diagram illustrating the role of a service data flow template in detecting the downlink portion of a service data flow.

[0021] Fig.13 is a diagram illustrating the role of a service data flow template in detecting the uplink portion of a service data flow.

[0022] Fig.14 is a diagram illustrating a flow-based QoS architecture using control plane signaling.

[0023] Fig.15 is a diagram illustrating a Long Term Evolution (LTE) layer 2 structure.

[0024] Fig.16 is a diagram illustrating a scheduling example in LTE.

[0025] Fig.17is a diagram illustrating an example of LTE logical channel priorities for MAC multiplexing.

[0026] Fig.18 is a diagram illustrating example signaling of buffer status and power headroom reporting.

[0027] Fig.19A , Fig.19B and Fig.19C Illustration illustrating an example Radio Access Network (RAN) slicing architecture model.

[0028] Fig. 20 is a diagram illustrating an example of parameter set multiplexing on a carrier.

[0029] Fig.21 A diagram illustrating an example of sectorized cell coverage with the aid of beams.

[0030] Fig. 22 is a call flow illustrating an example of logical channel (or radio bearer) mapping configuration signaling.

[0031] Fig.23 is a call flow illustrating an alternative example of logical channel (or radio bearer) mapping configuration signaling.

[0032] Fig.24 is a call flow illustrating an example of logical channel (or radio bearer) mapping configuration signaling performed in two stages.

[0033] Fig.25 is a diagram illustrating an alternative example of logical channel (or radio bearer) mapping configuration signaling in two stages.

[0034] Fig.26 is a diagram illustrating an example of a radio resource control (RRC) logical channel configuration information element (IE).

[0035] Fig. 27 is a diagram illustrating an example of an RRC configuration parameter set structure.

[0036] Fig.28 is a diagram illustrating an example uplink (UL) L2 structure (slice-specific resource blocks (RBs), logical channels, and MAC).

[0037] Fig.29 is a diagram illustrating an example UL L2 structure (slice-specific RBs, logical channels and MAC, beam configuration transparent to MAC).

[0038] Fig.30 is a diagram illustrating an example UL L2 structure (slice-specific RBs & logical channels, common MAC).

[0039] Fig.31 is a diagram illustrating an example UL L2 structure (slice-specific RBs & logical channels, common upper MAC, and slice-specific HARQ for each serving cell).

[0040] Fig.32 is a diagram illustrating an example UL L2 structure (common RBs, logical channels, common upper MAC, and slice-specific HARQ for each serving cell).

[0041] Fig.33 is a diagram illustrating an example UL L2 structure (common RBs, logical channels, common upper MAC, one HARQ per serving cell, and slice-specific shared channels).

[0042] Fig.34 is a diagram illustrating an example UL L2 structure, slice-specific RBs, slice-specific logical channels, slice-specific MAC or common MAC.

[0043] Fig.35 is a diagram illustrating example control plane signaling including pre-authorization of QoS specifications.

[0044] Fig.36 is a diagram illustrating an example data radio bearer (DRB) configuration.

[0045] Fig.37 is a diagram illustrating packet flow and an example DRB activation process.

[0046] Fig.38 is a diagram illustrating example association options between DRBs and packet flows.

[0047] Fig.39 is a diagram illustrating an example overview model of a Flow Encapsulation Protocol (FEP) sublayer in a downlink.

[0048] Fig.40 is a diagram illustrating an example overview model of the FEP sublayer in the uplink.

[0049] Fig.41 is a diagram illustrating an example FEP data PDU.

[0050] Fig.42 is a diagram illustrating an example of resource allocation by a gNB to a UE, where the UL resource grant is parameter set specific.

[0051] Fig.43 is a diagram illustrating an example of resource allocation by a gNB to a UE, where the UL resource grant is not specific to any parameter set configured for the UE.

[0052] Fig.44 is a diagram illustrating an example in which a UE splits a parameter set common resource grant into parameter set specific resource grants across logical channels.

[0053] Fig.45 is a diagram illustrating updating logical channel priorities based on an example of strict NW slice decremental priority.

[0054] Fig.46 is a diagram illustrating a process of updating logical channel priorities based on an example of slice-prioritized bit rate (SPBR).

[0055] Fig.47 is a diagram illustrating a process of updating logical channel priority based on an example of strict parameter set decremental priority.

[0056] Fig.48 is a diagram illustrating a process of updating logical channel priorities based on an example of a parameter set prioritized bit rate (NPBR).

[0057] Fig.49 is a diagram illustrating an example of logical channel priorities based on two priority types.

[0058] Fig.50 is a diagram illustrating an example user interface (UI) for application / slice mapping.

[0059] Fig.51 is a diagram illustrating example signaling between a UI and a modem.

[0060] Fig.52A One embodiment of an example communication system is illustrated in which the methods and apparatus described and claimed herein may be embodied.

[0061] Fig.52B is a block diagram of an example device or apparatus configured for wireless communication according to embodiments illustrated herein.

[0062] Fig.52C is a system diagram of a RAN and a core network according to an embodiment.

[0063] Fig.52D is a system diagram of a RAN and a core network according to yet another embodiment.

[0064] Fig.52E is a system diagram of a RAN and a core network according to another embodiment.

[0065] Fig.52F This can be reflected in Fig.52A , 52C, 52D and 52E illustrate an example computing system of one or more devices of the communication network.

[0066] Fig.53 An example flow of Logical Channel Prioritization (LCP) according to an example embodiment is illustrated.

[0067] Fig.54 An example flow diagram illustrating a portion of an LCP.

[0068] Fig.55 An example flow diagram illustrating another portion of the LCP process.

[0069] Fig.56 Yet another example flow of a portion of an LCP is illustrated.

[0070] Fig.57 Another example flow diagram of a portion of an LCP is illustrated. DETAILED DESCRIPTION

[0071] See first Figure 1A -C, in 3GPP TR 23.799, Study on Architecture for Next Generation System, V0.7.0, an architecture option for multiple packet data unit (PDU) sessions over different accesses is described. The option includes the following example cases: multiple PDU sessions ( Figure 1A ); Multiple PDU sessions through different accesses to the same data network ( Figure 1B ); and a PDU session through different accesses to the same data network, which may be referred to as a multiple access PDU session ( Figure 1C ).

[0072] As shown in the figure, NG1 indicates the reference point of the control plane between the next generation (NextGen) user equipment (UE) and the next generation core network or core. NG2 indicates the reference point of the control plane between the next generation radio access network or access network (R)AN and the next generation core. NG3 indicates the reference point of the user plane between the next generation (R)AN and the next generation core. NG4 indicates the reference point between the NG core control function and the NG user plane function. NG5 indicates the reference point between the NG control function and the application function. NG6 indicates the reference point between the next generation core and the data network. The data network can be a public or private data network external to the operator, or a data network within the operator. NG-U refers to the user plane interface between the gNB and the next generation core network (NGC). Unless otherwise specified, NG2 and NG-U can be used interchangeably in this document without limitation. NG-C refers to the control plane interface between the gNB and the NGC. Unless otherwise specified, NG3 and NG-C can be used interchangeably in this document without limitation. NR Uu refers to the radio interface between the gNB and the UE. NG1 is the reference point between Next Generation UE and Next Generation Core over NR Uu. The term gNB used in this article refers to a New Radio (NR) node, such as a logical access network node or a radio access network node.

[0073] Unless otherwise specified, the access network (AN) and radio access network (RNA) used in this document may be used interchangeably without limitation. In addition, the terms gNB, access network node, access network function, radio access network node, and radio access network function may be used interchangeably in this document without limitation, unless otherwise specified. The access network CP function (AN CP function) or AN CP node used in this document may refer to a logical node that implements the control plane function of a gNB, access network node, access network function, radio access network node, or radio access network function. Similarly, the access network UP function (AN UP function) or AN UP node may refer to a logical node that implements the user plane function of a gNB, access network node, access network function, radio access network node, or radio access network function.

[0074] See now Figure 2 , the example system architecture 200 allows for decoupling and independent evolution of access networks and core networks. As shown, an example deployment use case (Case 1) is for 3GPP access only, an example deployment use case (Case 2) is for non-3GPP access under the umbrella of controlled 3GPP access, and another example deployment use case (Case 3) is for independent non-3GPP access. Although the decoupling between CP and UP is illustrated in the core network, similar decoupling between the control plane and the user plane can be achieved in the wireless access network.

[0075] See also Figure 3 , the figure shows an example in which the upper layers of the new RAN radio protocol stack are concentrated in the central unit 302. Different protocol splitting options between the lower layers of the central unit 302 and the NR BS node 304 are possible. Figure 4 , example protocol segmentation options are described as options 1-8.

[0076] Turning now to the bearer types used for dual connectivity between LTE and NR, various types of bearers support dual connectivity between LTE radio and New Radio (NR). Figure 5 The diagram illustrates an example of split bearer through a primary cell group (MCG). In this example scenario, the core network can be an evolved packet core network (EPC) or a next generation (NextGen) core network (NG CN). Example 504 describes an example scenario where LTE is a secondary cell group (SCG) and NR is an MCG. In this example scenario, the core network is a next generation (NextGen) core network (NG CN). Figure 6 The diagram illustrates an example of split bearer by secondary cell group (SCG). Example 602 describes a scenario where LTE is an MCG and NR is an SCG. In this scenario, the core network can be an evolved packet core network (EPC) or a next generation (NextGen) core network (NG CN). Example 604 describes a scenario where LTE is an SCG and NR is an MCG. In this scenario, the core network is a next generation (NextGen) core network (NG CN). Figure 7 The diagram illustrates an example of a secondary cell group bearer. For example, the bearer can be routed directly from the core network to the SCG. Example 702 describes a situation where LTE is an MCG. In this case, the core network can be an evolved packet core network (EPC) or a next generation (NextGen) core network (NG CN). Example 704 describes a situation where LTE is an SCG and NR is an MCG. In this case, the core network is a next generation (NextGen) core network (NG CN).

[0077] Now turning to network slicing, Figure 8 A high-level illustration describing an example network slicing concept. A network slice may consist of a collection of logical network functions that support the communication service requirements of one or more specific use cases. In some cases, terminals may be directed to a selected slice in a manner that meets operator or user requirements. For example, a terminal (UE) may be directed to a selected slice based on subscription or terminal type. Network slicing may be directed to partitions of the core network. In some cases, a radio access network (RAN) may require specific functionality to support multiple slices, or to support the partitioning of resources for different network slices. Fig. 9An example of the use of network slicing is described in .

[0078] Now turning to the Quality of Service (QoS) framework for next generation systems, Fig.10 An example distribution of QoS functions between a core network (CN) 1002, a radio access network (RAN) 1004, and a user equipment (UE) 1006 is described. QoS parameters may include one or more of the following parameters given by way of example and not limitation:

[0079] Flow Priority Indicator (FPI), which may define the priority of each flow treatment at the UP and AN functions. It may correspond to scheduling priority, as well as priority treatment in congestion situations. This may be similar to the priority defined in existing systems with the help of standardized QCI.

[0080] Flow Priority Level (FPL), which may define the relative importance of flows accessing AN resources. This may be similar to the Allocation and Retention Priority (ARP) defined in existing LTE systems.

[0081] Packet Priority Indicator (PPI), which can define the scheduling priority of each packet at the UP and AN functions. Packets in the same flow can be marked with different PPIs.

[0082] • Packet Drop Priority Indicator (PDPI), which can define the drop priority of each packet, for example in case of congestion, to differentiate content within the same flow. In some cases, the PDPI marking in the downlink is set by the UP function and used by the AN.

[0083] Maximum stream bitrate (DL, UL): UL and DL bitrate values ​​applicable to a single stream or an aggregation of streams. It may indicate the maximum bitrate authorized for the data stream identified by the stream descriptor.

[0084] Guaranteed Stream Bitrate (DL, UL): UL and DL bitrate values ​​applicable to a single stream or an aggregation of streams. It may indicate the guaranteed bitrate granted for a data stream.

[0085] • Session bitrate (DL, UL): UL and DL bitrate values ​​applicable for an established user session. It may indicate the maximum bitrate authorized for the user session.

[0086] • Reflective QoS Indication (RQI): A DL indication applicable to a single flow or an aggregation of flows. When used as a U-plane marking, it can be determined by the UP function and can be applied on a per-packet basis during the lifetime of a flow.

[0087] Resource type: GBR or non-GBR.

[0088] Packet delay budget, which defines the upper limit of the time a packet can be delayed between the UE and the UP function.

[0089] Packet loss rate, which may define an upper limit on the rate of SDUs (e.g., IP packets) that have been processed by the sender of the data link layer protocol (e.g., RLC in E-UTRAN) but have not been successfully delivered to the upper layers (e.g., PDCP in E-UTRAN) by the corresponding receiver.

[0090] Reliability, which may define the probability of successfully transmitting X bytes within a latency range. For example, for URLL, a target for user plane latency of 0.5 ms for UL and 0.5 ms for DL ​​implies a round trip delay of 1 ms, or equivalently a maximum retransmission latency of 1 ms. A reliability of 1-10-5 within a latency of 1 ms implies a reliability of 1-10-5 with a retransmission latency of no more than 1 ms. This is the case for a URLL application with a target reliability of 1-10-5 within a latency range of 1 ms.

[0091] • Allocate and maintain priorities, which may include information about priority levels, preemption capabilities, and preemption capabilities. In some cases, the priority levels define the relative importance of resource requests.

[0092] QoS ID, which can be used as a pointer to the QoS specification.

[0093] Unless otherwise specified, the PDU (Packet Data Unit) connection service used in this article refers to a service that provides the exchange of PDUs between the UE and the data network. Unless otherwise specified, a PDU session refers to an association between a UE and a data network that provides a PDU connection service. The types of associations may include IP type, Ethernet type, and non-IP type. A PDU session of IP type may refer to an association between a UE and an IP data network. A PDU session may include one or more service data unit streams. Unless otherwise specified, an application detection filter used in this article refers to a logic for detecting these packets based on an extended inspection of packets generated by an application (e.g., header and / or payload information). The dynamics of a packet stream may also be detected. Unless otherwise specified, an application identifier refers to an identifier that relates to a specific application detection filter. Unless otherwise specified, a service data unit flow (SDF) refers to an aggregate set of packet flows that may be transported by matching the execution function and policy control of a service data flow template. For convenience, this may also be referred to as a packet flow, where a packet flow may be a specific user data flow from and / or to a UE. Multiple packet flows corresponding to specific service data flow filters, respectively, may belong to an SDF.

[0094] Unless otherwise specified, the service data flow filter used in this article refers to a set of packet flow header parameter values / ranges for identifying one or more of the packet flows. This may also be referred to as a service flow filter (TFF), which may be classified as a flow descriptor that may be specified for DL ​​and / or UL. A service data flow filter template may refer to a set of service data flow filters or application identifiers that may be required to define an SDF. In this article, this may also be referred to as a service flow template (TFT). A service data flow filter identifier may be a scalar unique to a specific service data flow (SDF) filter (e.g., used on an interface between a CN CP policy function and an execution function in a CP UP) within a PDU session. A service data flow template may refer to a set of service data flow filters involving an application detection filter, and may be necessary to define a service data flow. A service identifier refers to an identifier for a service. A service identifier may provide the most detailed identification of a service data flow for a flow-based charging provision. In some cases, if additional AF information is available, a specific instance of a service may be identified. An IP CAN session may refer to an association between a UE and an IP network. An IP CAN session may be considered as an IP type PDU session. The IP CAN bearer may refer to an IP transmission path of specified capacity, delay, bit error rate, etc. From the perspective of the end-to-end system, the IP CAN bearer may include a concatenation of EPS bearers, radio access bearers (RABs), and data radio bearers (DRBs). Unless otherwise specified, the packet tag (or marker) used in this article refers to a tag contained in the packet encapsulation header to uniquely associate a data packet characterized by a given service flow filter (TFF) or service flow filter template (TFT) with a predetermined matching QoS specification. Each QoS specification can be associated and identified by a tag. Unless otherwise specified, the QoS specification used in this article may refer to a combination of all or a subset of the QoS parameters defined above. For downlink services, in some cases, the UP function located in the CN may apply a tag to each packet before transmitting the packet to the access network. In the access network, the UP function may apply a packet tag before transmitting the packet to the UE through the wireless interface. In the uplink, the UE may apply a packet tag before transmitting the packet to the access network. The access network may apply a packet tag before relaying the packet to the core network. QoS rules generally refer to information that enables detection of service data flows and defines their associated QoS parameters or specifications, including, for example, QoS markings.

[0095] See now Fig.11, the example system 1100 illustrates the relationship between service data flows, packet flows, service data flow templates, and service data flow filters. For IP type PDU sessions, the service data flow filter identifying the service data flow may identify a pattern for matching an IP 5-tuple (e.g., source IP address or IPv6 network prefix, destination IP address or IPv6 network prefix, source port number, destination port number, protocol ID of a protocol over IP). An example detection process for identifying packets belonging to a service data flow is illustrated in Fig.12 (downlink) and Fig.13 For downlink traffic, the downlink portion of the service data flow template associated with the IP-CAN session of the destination address is a match candidate in the detection process. For uplink traffic, the uplink portion of all service data flow templates associated with the IP CAN bearer are match candidates in the detection process. Fig.14 This is an example of a call flow for control plane signaling of 3GPP TR 23.799.

[0096] Turning now to logical channels in Long Term Evolution (LTE), the physical layer provides information transfer services to the MAC layer and higher layers. The physical layer transport services are described by the manner and characteristics of data transmission over the radio interface. This is called a "transport channel". A transport channel is a SAP between MAC and Layer 1, and a logical channel is a SAP between MAC and RLC. The MAC layer provides data transfer services on logical channels. For the different kinds of data transfer services provided by MAC, a set of logical channel types are defined. Each logical channel type is defined by the type of information transmitted. In LTE, MAC provides control channels and traffic channels. The mapping of logical channels on transport channels depends on the multiplexing configured by RRC. Fig.15 Describes an example LTE data link (L2) structure and LTE logical channels.

[0097] Now turning to scheduling and QoS differentiation in LTE, see Fig.16 ,The scheduler in LTE uses the QoS configuration from the core network and inputs from the UE, such as the Buffer Status Report (BSR), Power Headroom Report (PHR), and Channel State Indication (CSI) from the UE, to make scheduling decisions and provide QoS differentiation for downlink and uplink services. In LTE, QoS differentiation is provided at the granularity of the bearer class.

[0098] With respect to logical channel priorities, a logical channel priority process may be applied for uplink transmissions when a new transmission is made. In an example, RRC controls scheduling of uplink data by, for each logical channel, signaling a priority in which an increasing priority value indicates a lower priority level, setting a prioritized bit rate (PBR) of a prioritized bit rate, and setting a bucketSizeDuration of a bucket size duration (BSD). For NB-IoT, the prioritizedBitRate, bucketSizeDuration, and corresponding steps of the logical channel priority process (e.g., steps 1 and 2 below) are not applicable.

[0099] In some cases, the MAC entity maintains a variable Bj for each logical channel j. Bj is initialized to 0 when the associated logical channel is established and is incremented for each TTI by the product PBR × TTI duration, where PBR is the priority bit rate of logical channel j. However, the value of Bj must never exceed the bucket size. If the value of Bj is greater than the bucket size of logical channel j, then it is set to the bucket size. The bucket size of a logical channel is equal to PBR × BSD, where PBR and BSD are configured by upper layers.

[0100] In some cases, when a new transmission is made, the MAC entity performs the following logical channel priority processing. The MAC entity allocates resources to logical channels according to the following steps. In step 1, all logical channels with Bj>0 are allocated resources in descending order of priority. If the PBR of the logical channel is set to "infinity", the MAC entity allocates resources for all data available for transmission on the logical channel before the PBR of the lower priority logical channel is met. In step 2, the MAC entity decrements Bj by the total size of the MAC SDU that serves logical channel j in step 1. The value of Bj can be a negative value. In step 3, in some cases, if any resources remain, all logical channels are served in a strictly descending priority order (regardless of the value of Bj) until the data for the logical channel or the UL grant is exhausted, whichever comes first. Logical channels with the same priority should receive equal service.

[0101] For the example logical channel priority handling process, the MAC entity considers the following relative priorities in descending order: MAC control elements for cell radio network temporary identifier (C-RNTI) or data from UL-CCCH; MAC control elements for BSR (except BSR included for padding); MAC control elements for PHR, extended PHR or dual connection PHR; MAC control elements for sidelink BSR (except sidelink BSR included for padding); data from any logical channel except data from UL-CCCH; MAC control elements for BSR included for padding; MAC control elements for sidelink BSR included for padding.

[0102] When the MAC entity is requested to send multiple MAC PDUs in one TTI, the above steps 1-3 and associated rules can be applied to each grant individually, or to the sum of the granted capacities. In addition, the order in which the grants are processed is determined by the UE implementation. When the MAC entity is requested to send multiple MAC PDUs in one TTI, it is up to the UE implementation to decide in which MAC PDU the MAC Control element is included. When the UE is requested to generate MAC PDUs in two MAC entities in one TTI, it is up to the UE implementation to decide in which order the grants are processed. The MAC entity multiplexes the MAC Control element and the MAC SDU in the MAC PDU as described above.

[0103] Fig.17 An example of LTE logical channel priority operation for MAC multiplexing is described in , where channel 1, channel 2, and channel 3 are in decreasing priority. Following this example, channel 1 is first served by reaching its PBR, channel 2 is served by reaching its PBR, and then channel 3 is served with as much available data as possible (because in this example, the amount of available data is less than the amount of data that the PBR configured for that channel would allow). Thereafter, the remaining space in the MAC PDU is filled with data from channel 1, which has the highest priority, until there is no more space in the MAC PDU, or there is no more data from channel 1. If there is still space after serving channel 1, then channel 2 can be served in a similar manner.

[0104] Turning now to the buffer status report, the buffer status report can be used to provide the serving eNB with information about the amount of data available for transmission in the UL buffer associated with the MAC entity. RRC controls BSR reporting by configuring timers (periodicBSR-Timer, retxBSR-Timer and logicalChannelSR-ProhibitTimer) and by, for each logical channel, optionally signaling the logicalChannelGroup that assigns the logical channel to the LCG. A buffer status report (BSR) can be triggered if any of the following events occurs:

[0105] The arrival of data with a higher priority than the data currently in the transmit buffer (i.e., data in a logical channel group with a higher priority than the data currently being transmitted), as this may affect the scheduling decision

[0106] Change of serving cell, in which case the buffer status report can be used to provide information about the conditions in the terminal to the new serving cell

[0107] ·Triggered periodically by a timer

[0108] Replace padding. If the amount of padding required to match the scheduled transport block size is larger than the buffer status report, then insert a buffer status report

[0109] In addition to the buffer status, the amount of transmit power available in each terminal may also be relevant to the uplink scheduler. On the UL-SCH, a power headroom report (PHR) is reported to the terminal in a similar manner to the BSR. The PHR can be triggered periodically by a timer, triggered by a change in path loss (e.g., when the difference between the current power headroom and the last report is greater than a configurable threshold), or triggered instead of padding.

[0110] Different types of PHR are defined. Type 1 reports reflect the power headroom assuming only PUSCH transmission on the carrier. Type 2 reports assume both PUSCH and PUCCH transmission. Type 1 reports are provided for all carriers, while Type 2 reports are provided only for the primary component carrier, since PUCCH can only be transmitted on the primary component carrier. Fig.18 The signaling of buffer status report and power headroom report is illustrated in FIG.

[0111] As far as scheduling requests in LTE are concerned, the scheduler needs knowledge of the terminals that have data to send and therefore need to be scheduled for uplink resources. There is no need to provide uplink resources to terminals that have no data to transmit, as this would only result in padding by the terminal to fill the granted resources. Thus, the scheduler needs to know at least whether the terminal has data to send and whether it should be given a grant. This is called a scheduling request. Scheduling requests are used for terminals that do not have a valid scheduling grant. A scheduling request is a simple flag (bit) established by the terminal to request uplink resources from the uplink scheduler. Each terminal can be assigned a dedicated PUCCH scheduling request resource that appears every n-1 subframes. With a dedicated scheduling request mechanism, there is no need to provide the identity of the terminal requesting to be scheduled, as the identity of the terminal is implicitly known from the resource on which the request is sent. When data with a higher priority than the data already present in the transmit buffer arrives at the terminal, but the terminal does not have a grant and therefore cannot send the data, the terminal sends a scheduling request at the next possible time. Upon receiving the request, the scheduler can grant a grant to the terminal. If the terminal does not receive a scheduling grant until the next possible scheduling request time, the scheduling request is repeated. In case of carrier aggregation, the scheduling request is sent on the primary component carrier in line with the general principle of PUCCH transmission only on the primary component carrier. No matter how many uplink component carriers the terminal can support, there is only one scheduling request bit.

[0112] In the uplink, E-UTRAN can dynamically allocate resources (physical resource blocks PRB and modulation and coding scheme MCS) to the UE in each transmission time interval (TTI) through the C-RNTI on the PDCCH. Resources are allocated in the form of resource block pairs. A resource block pair corresponds to a time-frequency unit of 1ms by 180kHz. The UE always monitors the PDCCH to find out possible allocations for uplink transmission when its downlink reception is allowed (an activity managed by discontinuous reception (DRX) when configured). When carrier aggregation (CA) is configured, the same C-RNTI applies to all serving cells.

[0113] In addition, the E-UTRAN may allocate semi-persistent uplink resources to the UE for the first HARQ transmission and possibly for retransmission. The RRC may define the periodicity of the semi-persistent uplink grant, and the physical downlink control channel (PDCCH) may indicate whether the uplink grant is a semi-persistent uplink grant (e.g., whether it can be implicitly reused in the next TTI according to the periodicity defined by the RRC).

[0114] In subframes where the UE has semi-persistent uplink resources, if the UE cannot find its C-RNTI on the PDCCH, then uplink transmissions may be made according to the semi-persistent allocation that the UE has been assigned in the TTI. In some examples, the network decodes the pre-defined PRBs according to the pre-defined MCS. Otherwise, in subframes where the UE has semi-persistent uplink resources, for example, if the UE finds its C-RNTI on the PDCCH, then the PDCCH allocation overrides the permanent allocation for that TTI and the UE's transmissions follow the PDCCH allocation rather than the semi-persistent allocation. Retransmissions may be either implicitly allocated, in which case the UE utilizes the semi-persistent uplink allocation, or explicitly allocated via the PDCCH, in which case the UE does not follow the semi-persistent allocation. In some cases, there is no blind decoding in the uplink and padding is used when the user does not have enough data to fill the allocated resources.

[0115] When a UE is provided with a valid uplink grant in several serving cells in one TTI, in some cases the order in which the grants are processed during logical channel priority processing, and whether joint processing or serial processing is applied, is decided by the UE implementation while complying with the transmission restrictions of the logical channels over the LTE Enhanced Access (LAA) SCell.

[0116] Similarly, for the downlink, in some cases, semi-persistent uplink resources may be configured only for the PCell, and only PDCCH allocations for the PCell may override the semi-persistent allocations. When configuring downlink control (DC), in some cases, semi-persistent uplink resources may be configured only for the PCell or the PSCell. In each example, only PDCCH allocations for the PCell may override semi-persistent allocations for the Pcell, and only PDCCH allocations for the PSCell may override semi-persistent allocations for the PSCell.

[0117] In LTE, a Transmission Time Interval (TTI) is defined as a fixed duration (e.g., 1 ms) with the same value in both UL and DL. The TTI duration (e.g., TTI length) is the minimum periodicity of scheduling opportunities (PDCCH monitoring period). For example, in case of dynamic UL scheduling, the network may signal the UE with scheduling grant information every TTI. In case of semi-static resource allocation schemes like semi-persistent scheduling (SPS), the UL scheduling opportunity periodicity may be greater than the TTI duration, because the network attempts to reduce scheduling overhead by providing the UE with a scheduling grant through semi-static signaling (e.g., RRC signaling), which indicates that the scheduling grant is applicable every n subframes, i.e. until further notice. Once configured through RRC signaling, the SPS scheduling grant can be activated or deactivated by (E)PDCCH signaling using the SPS C-RNTI. In LTE, the PDCCH monitoring period is exactly the same as the UL transmission time interval. Similarly, the PDCCH monitoring period is the same as the DL transmission time interval. Table 1 below provides an overview of the NR parameter sets and their key parameters. There is a proportional relationship between the duration of a symbol of a parameter set and the duration of a slot or mini-slot.

[0118] In the following Tables 1, 2 and 3, the parameters Indicates the number of OFDM symbols in each time slot; parameter Indicates the number of time slots in each radio frame; parameter Indicates the number of time slots in each radio subframe.

[0119] Table 1: Example of proportional relationship between symbol and slot (or mini-slot) duration on NR parameter set

[0120]

[0121] Table 2: Number of OFDM symbols per slot for standard cyclic prefix

[0122]

[0123] Table 3: Number of OFDM symbols per slot for extended cyclic prefix

[0124]

[0125] Here, it is recognized that the existing LTE design provides limited support for UL service differentiation. The QoS requirements and / or service differentiation mapping to UR authorization are not deterministic. The highest QoS requirements are enforced for all multiplexed services. This leads to suboptimal utilization of radio resources. 3GPP adopted this non-deterministic service based authorization design based on complexity and performance trade-off analysis. LTE design decisions regarding UL QoS differentiation can be re-discussed in the context of new generation wireless network system architectures. Here, it is recognized that LTE limitations may be worse in view of the diverse 5G use cases.

[0126] As discussed in this article, the use of network slicing and physical layer parameter set multiplexing can support different and conflicting requirements of target use cases for next generation cellular systems (commonly referred to as 5G systems). Depending on the radio access network (RAN), several architectural models for network slicing are possible. In one model ( Fig.19A In the model 1) shown in , it is assumed that there is a network slice-specific control plane, a network slice-specific user plane, and a network slice-specific physical resource. Another model ( Fig.19B The model shown in 2) envisions a network slice-specific control plane, a network slice-specific user plane, a network slice-specific scheduler, and an optional common pool of physical resources. In this model, a common management network function allocates / reallocates physical resources between slices. Once resources are allocated to a slice, the slice is specific to the physical resource. Another model ( Fig.19C The model shown in 3) sets up a shared network slice control plane, a shared network slice user plane, a shared network slice scheduler and physical resources. Fig. 20 An example of numerology multiplexing on a carrier is illustrated in It is recognized here that the New Radio (NR) architecture can be beam-centric. Fig.21 An example of sectorized cell coverage with the help of beams is illustrated in FIG.

[0127] Described here is the mechanism for allocating resource grants by the NR node and the mechanism for allocating resource grants received by the UE to UL services. Specifically, the envisioned data link structure, resource grant allocation by the NR node, the option of allocating resource grants received by the UE to UL services, the option of buffer status reporting, the option of power headroom reporting, and the option of scheduling request are now described.

[0128] In terms of the L2 (data link) structure, a parameter set may be defined by a combination of one or more of the following parameters given as examples and not limitations: subframe duration, guard time interval, number of symbols per subframe, subcarrier spacing, and transmit time interval (TTI). In some cases, a parameter set may be associated with more than one TTI. TTIs may be defined at a slot granularity level (e.g., 7 or 14 OFDM symbols) or at a mini-slot granularity level. A mini-slot may be defined as one or more symbols. A parameter set may be associated with a bandwidth part (BWP). The bandwidth of a carrier may be divided into BWPs, each BWP being configured with a given parameter set. The gNB may reconfigure the parameter set of a BWP for a UE. Unless otherwise specified, parameter sets and BWPs used herein may be used interchangeably without limitation.

[0129] Turning now to the radio bearer (RB) model, unless otherwise specified herein, a radio bearer may be used to represent a data radio bearer or a signaling radio bearer. Now consider the model for a radio bearer (signaling radio bearer or data radio bearer). In one example, the RB is specific to each network slice configured for the UE. For example, data belonging to different network slices is mapped to different sets of RBs within the UE context, where the RB configuration is specific to each network slice configured for the UE. Each network slice may have more than one RB configured per UE. For example, any major next-generation system use case (e.g., eMBB, URLL, or mMTC) may cover a wide range of applications with different QoS requirements. Several RBs may then be configured within the UE context, for example to support an eMBB network in order to provide differentiated QoS. The model may correspond to a scenario in which a RAN network is sliced, for example to support different core network slices, where the core network slice is associated with the RAN network slice by static configuration or semi-static configuration (e.g., at session establishment).

[0130] In another example model, the RB is common to the network slice configured for the UE. For example, the RB configuration may not be specific to a network slice. In one embodiment, data from different network slices may be mapped to the same RB at the same time, and the data from different RBs may be data generated by the same network slice. This model may correspond to a scenario where, for example, the RAN network is not sliced.

[0131] In another example, the RB configuration is specific to each parameter set configured for the UE. For example, in some cases, each RB may be associated with only one PHY parameter set within the UE context, and the data carried by the RB may be mapped to only one PHY parameter set. Each PHY parameter set may be associated with more than one RB within the UE context. The radio bearer may be reconfigured to another PHY parameter set. As an example of this embodiment, and since a parameter set may have more than one TTI, the gNB may configure the UE with a radio bearer (data radio bearer or signaling radio bearer) mapped to only one parameter set with one or more TTIs. For the same bearer, the gNB may configure the UE with a mapping of a radio bearer (data radio bearer or signaling radio bearer) to a parameter set and / or TTI in the uplink direction that is different from the mapping of the radio bearer (data radio bearer or signaling radio bearer) to the parameter set and / or TTI in the downlink direction.

[0132] In another example, the RB configuration may be common to the physical layer (PHY) parameter set configured for a given UE. For example, the RB configuration may not be specific to a PHY parameter set. For example, as a result of a MAC scheduling decision, data on a given RB may be dynamically (over time) mapped to different parameter sets. As an example of this embodiment, the gNB may configure the UE with radio bearers mapped to more than one parameter set, each parameter set having one or more TTIs. For the same radio bearer (data radio bearer and signaling radio bearer), the gNB may configure the UE with different mappings of radio bearers to parameter sets and / or TTIs in the downlink direction and uplink direction. For example, for each radio bearer that the UE is configured with, the set of parameter sets and / or TTIs in the UL direction to which the radio bearers are mapped may be different from the set of parameter sets and / or TTIs in the downlink direction to which the logical channels are mapped. Similarly, multiple RBs may share the same parameter set. For example, in a UE in the uplink direction, data from more than one RB may be mapped to the same parameter set as a result of a MAC scheduling decision. In some cases, different layers in spatial multiplexing may belong to different parameter sets.

[0133] In another aspect, the example RB models described above may be combined. For example, in some cases, some RBs may be configured to be network slice specific, while some other RBs may be configured as common RBs between two or more network slices. Common signaling radio bearers (SRBs) may be used to support UE configuration and control plane signaling for more than one network slice. For example, the core network operation may have a common control plane network slice. NAS signaling associated with the common control plane may be mapped to a common SRB in the radio access network. The radio access network itself may have a common control plane RAN slice mapped to a common core network control plane slice. In another example, the gNB may configure the UE with one radio bearer mapped to only one parameter set with one or more TTIs, and another radio bearer mapped to more than one parameter set mapped to one or more TTIs. In addition, the mapping of parameter sets and / or TTIs of a radio bearer to a direction (e.g., uplink (UL) direction or downlink (DL) direction) may vary from one radio bearer to another radio bearer of the same UE.

[0134] In some cases, the configuration of the mapping of radio bearers to parameter sets and / or TTIs may be considered as a one-stage or two-stage process. In an example one-stage process, the gNB may signal the UE with the mapping of radio bearers to parameter sets and / or TTIs during an RRC connection establishment, RRC connection reconfiguration, or RRC connection recovery procedure. In an example, the gNB may also configure the UE with the mapping of radio bearers to parameter sets and / or TTIs using MAC control element (MAC CE) signaling. The UE may consider all mapping configurations that are valid, for example, upon successful completion of the process. In an example two-stage process, the UE is first (stage 1) configured with possible mappings between configured radio bearers and parameter sets and / or TTIs via RRC signaling, for example, during an RRC connection establishment or RRC connection reconfiguration. In a second stage, the gNB instructs the UE to activate (use) some or all of the mapping configurations received during the first stage via MAC CE signaling. In one embodiment, the gNB configures the UE with the mapping of radio bearers to parameter sets and / or TTIs via explicit mapping. For example, the UE may be explicitly configured in the uplink and / or in the downlink, with parameter sets and / or TTIs allowed for each radio bearer. In another embodiment, the UE implicitly derives the mapping of radio bearers to parameter sets and / or TTIs. For example, for each radio bearer, the gNB configures the UE with parameter sets and / or TTIs not allowed in the uplink and / or in the downlink for that radio bearer. For each radio bearer, the UE utilizes the configuration from the gNB to identify which parameter sets and / or TTIs are allowed by the gNB and which are not allowed by the gNB.

[0135] Turning now to an example logical channel model (e.g., control and traffic channels), in one example, the logical channels are specific to each network slice configured for the UE. For example, data belonging to different network slices, including data of a MAC control element (MAC CE), is mapped to different sets of logical channels within the UE context, where the logical channel configuration is specific to each network slice configured for the UE. Each network slice may have more than one logical channel configured per UE. For example, any major next-generation system use case (e.g., eMBB, URLL, or mMTC) may cover a wide range of applications with different QoS requirements. Several logical channels may then be configured within the UE context, such as to support an eMBB network in order to provide differentiated data transfer service access points to the MAC layer, thereby providing differentiated QoS. The model may correspond to a scenario in which a RAN network is sliced, such as to support different core network slices, where the core network slice associated with the RAN network slice is configured by static configuration or semi-static configuration (e.g., at session establishment).

[0136] In another logical channel example, the logical channel is common to the network slices configured for the UE. For example, the logical configuration may not be specific to a network slice. This may be the case for a deployment scenario where the RAN is not sliced, but the core network is sliced. Data from different network slices may be mapped to the same logical channel at the same time, and data from different logical channels may be data generated by the same network slice.

[0137] In another logical channel example, the logical channel configuration is specific to each parameter set configured for the UE. For example, in some cases, each logical channel may be associated with only one PHY parameter set within the UE context, and the data carried by the logical channel may be mapped to only one PHY parameter set. Each PHY parameter set may be associated with more than one logical channel within the UE context. Logical channels may be reconfigured to additional PHY parameter sets. As an example of this embodiment, and since a parameter set may have more than one TTI, the gNB may configure the UE with a logical channel mapped to only one parameter set with one or more TTIs. For the same logical channel, the gNB may configure the UE with a mapping of parameter sets and / or TTIs to the uplink direction that is different from the mapping of the logical channel to parameter sets and / or TTIs in the downlink direction.

[0138] In another example, a logical channel may be common to the physical layer (PHY) parameter sets configured for the UE. For example, the logical channel configuration may not be specific to a PHY parameter set. For example, as a result of a MAC scheduling decision, data on a given logical channel may be dynamically (over time) mapped to different parameter sets. For example, data on a logical channel corresponding to the BCCH may be mapped to a parameter set of a physical channel dedicated to information broadcast (e.g., PBCH), or to a parameter set of a physical downlink shared channel (such as PDSCH) used by other signaling or data services. As an example of this embodiment, the gNB may configure the UE with logical channels mapped to more than one parameter set, each parameter set having one or more TTIs. For the same logical channel, the gNB may configure the UE with different mappings of the logical channel to parameter sets and / or TTIs in the downlink direction and the uplink direction. For example, for each logical channel that the UE is configured with, a set of parameter sets and / or TTIs in the UL direction to which the logical channel is mapped may be different from a set of parameter sets and / or TTIs in the downlink direction to which the logical channel is mapped.

[0139] In some cases, two or more of the example logical models described above may be combined with each other. For example, some logical channels may be configured to be specific to a network slice, while some other logical channels may be configured to be common to two or more network slices. Logical channels mapped to common signaling radio bearers (SRBs) may be used to support network configuration and control plane signaling for more than one network slice. For example, the core network operation may have a common control plane network slice. NAS signaling associated with the common control plane may be mapped to a common SRB in the radio access network. The radio access network itself may have a common control plane RAN slice mapped to a common core network control plane slice. In another example, the gNB may configure the UE with one radio bearer mapped to only one parameter set with one or more TTIs, and another radio bearer mapped to more than one parameter set with one or more TTIs respectively. In addition, the mapping of parameter sets and / or TTIs of a radio bearer to a direction (e.g., uplink (UL) direction or downlink (DL) direction) may vary from one radio bearer to another radio bearer of the same UE.

[0140] In some cases, the configuration of the mapping of logical channels to parameter sets and / or TTIs can be a one-step (one-stage) process or a two-step (two-stage) process. In an exemplary one-stage embodiment, see Fig. 22 and 23, the gNB may signal the UE with the mapping of logical channels to parameter sets and / or TTIs during the RRC connection establishment procedure, the RRC connection reconfiguration procedure, or the RRC connection recovery procedure. The gNB may also configure the UE with the logical channel mapping to parameter sets and / or TTIs using MAC control element (MAC CE) signaling. In some cases, the UE considers all mapping configurations that are valid (e.g., applicable), for example, when the procedure is successfully completed. In the example two-stage embodiment, see Fig.24 and 25 , for example during RRC connection establishment or RRC connection reconfiguration, the UE is first configured (phase 1) via RRC signaling with possible mappings between configured logical channels and parameter sets and / or TTIs. In a second phase, the gNB instructs the UE to activate (use) some or all of the mapping configurations received during the first phase via MAC CE signaling. In one embodiment, the gNB configures the UE with the mapping of logical channels to parameter sets and / or TTIs via explicit mapping. For example, the UE may be explicitly configured in uplink and / or downlink with the parameter sets and / or TTIs allowed for each logical channel. In another embodiment, the UE implicitly derives the mapping of logical channels to parameter sets and / or TTIs. For example, for each radio bearer, the gNB configures the UE with the parameter sets and / or TTIs not allowed in uplink and / or downlink for that logical channel. For each logical channel, the UE uses the configuration from the gNB to identify which parameter sets and / or TTIs are allowed by the gNB and which are not allowed by the gNB.

[0141] To understand is to carry out Figure 22-25 The entities of the steps illustrated in the diagram may be logical entities implemented in the form of software (i.e., computer executable instructions) stored in a computer such as Fig.52B and F are shown in the memory of a device or computer system configured for wireless and / or network communication, and run on a processor of the device or computer system. That is, Figure 22-25 The method illustrated in the figure can be saved in a file such as Fig.52B and F are implemented in the form of software (i.e., computer executable instructions) in a memory of a device such as the device or computer system illustrated in FIG. 1 and F, which, when executed by a processor of the device, performs Figure 22-25 The steps shown in the diagram are also important to understand. Figure 22-25 Any sending and receiving steps illustrated in the diagram may be performed by the communication circuitry of the device under the control of the device's processor and computer-executable instructions (eg, software) executed by the processor.

[0142] Turning now to an example RRC logical channel configuration information element (IE), Fig.26Illustrate examples of the RRC Logical Channel Configuration IE and LogicalChannelConfig information element. Fig. 27 is a diagram illustrating an example of an RRC configuration parameter set structure. For each component carrier, the UE may be configured with a list of parameter sets, which may be, for example, Fig. 27 Each parameter set is defined as shown in the data structure of . In some cases, each parameter set within the entire set of parameter sets with which the UE is configured is indexed. The parameter NumerologyIndex in the structure points to a parameter set in the list of parameter sets configured for the UE. Each parameter set has a list of TTIs represented by the parameter tti-List. The possible values ​​of the TTI are listed (e.g., TTI x, TTI y, and TTI z). A parameter set can be configured with a list of TTIs, which is a subset of the possible values ​​of the TTI. Unless otherwise specified, in this document, the terms parameter set index and transmission profile are used interchangeably without limitation.

[0143] In terms of MAC architecture, various example models are now described. In one example, one MAC entity is configured in the UE. The MAC entity is common to all slices configured for the UE. In multiple connections (e.g., dual connections), one MAC entity is configured in the UE per connection with different schedulers in the network. Each of these MAC entities may be common to all slices configured for the UE. Multiple connections may refer to an operating mode in which a multi-Rx / Tx UE in connected mode is configured to utilize radio resources in E-UTRA and / or NR provided by multiple different schedulers connected via a non-ideal backhaul. For example, in dual connections, two MAC entities may be configured in the UE, one for the MCG and one for the SCG. Each MAC entity is common to the slices configured for the UE. In some examples, the MAC entity handles transport channels defined for NR, for example, the transport channels may be the NR equivalents of the following transport channels: broadcast channel (BCH), downlink shared channel (DL-SCH), paging channel (PCH), uplink shared channel (UL-SCH), random access channel (RACH), multicast channel (MCH), side link broadcast channel (SL-BCH), side link discovery channel (SL-DCH), side link shared channel (SL-SCH). In some cases, each MAC entity is configured by RRC to support serving cells for physical uplink control channel (e.g., LTE PUCCH or equivalent NR channel) transmission and contention-based random access. In the example, for each MAC entity, some of the transport channels may be configured per network slice configured in the UE for, for example, service transport channels (e.g., eMBB, URLL or mMTC). This may mean that even if there is no SCell, there may be multiple DL-SCHs (or NR equivalent DL transport channels), and there may be multiple UL-SCHs (or NR equivalent UL transport channels) and RACHs per MAC entity configured in the UE. If the MAC entity is configured with one or more SCells, there may be multiple DL-SCHs (or NR equivalent DL transport channels), and according to the MAC entity configured in the UE, there may be multiple UL-SCHs (or NR equivalent UL transport channels) and RACHs; there may be 1 DL-SCH and UL-SCH for each slice on the SpCell, there may be 1 DL-SCH, 0 or 1 UL-SCH for each slice, and 0 or 1 RACH for each SCell.

[0144] As another example, one MAC entity is configured in the UE for each slice. In multiple connections (dual connections), one MAC entity may be configured in the UE for each slice per connection with different schedulers in the network. Multiple connections refer to an operating mode in which multiple Rx / Tx UEs in connected mode are configured to utilize radio resources in E-UTRA and / or NR provided by multiple different schedulers connected through a non-ideal backhaul. For example, in dual connections, two MAC entities are configured in the UE for each slice, one for MCG and one for SCG. In this example scenario, in order to make the initial access process (e.g., random access process, paging, or SI information provision) common to all network slices, one MAC entity dedicated to the processing of the initial access process may be configured in the UE. In multiple connections (dual connections), one MAC entity dedicated to the processing of the initial access process is configured in the UE per connection with different schedulers in the network. The MAC entity is configured by RRC to support the serving cell for physical uplink control channel (e.g., LTE PUCCH or equivalent NR channel) transmission and contention-based random access. In some cases, the MAC entity handles transport channels defined for NR, for example, the NR equivalents of the following transport channels: broadcast channel (BCH), downlink shared channel (DL-SCH), paging channel (PCH), uplink shared channel (UL-SCH), random access channel (RACH), multicast channel (MCH), side link broadcast channel (SL-BCH), side link discovery channel (SL-DCH), side link shared channel (SL-SCH). Transport channels (e.g., service transport channels (e.g., eMBB, URLL, or mMTC)) may be configured per network slice configured in the UE. If the MAC entity is configured with one or more SCells, there are multiple DL-SCHs (or NR equivalent DL transport channels), and according to the MAC entity configured in the UE, there may be multiple UL-SCHs (or NR equivalent UL transport channels) and RACHs; there is 1 DL-SCH and UL-SCH for each slice on the SpCell, there may be 1 DL-SCH, 0 or 1 UL-SCH for each slice, and 0 or 1 RACH for each SCell.

[0145] In another example, a combination of the above examples is implemented where some MAC entities are common to network slices and some MAC entities are slice-specific.

[0146] The PHY parameter set is visible to the MAC sublayer. For each PHY parameter set configured for the UE, the UE MAC may have the relevant configuration (e.g., TTI, subcarrier spacing, CP length, frequency-time domain resource mapping, etc.). In another embodiment, the MAC configuration does not have an explicit parameter set configuration. In contrast, in some cases, a parameter set configuration is defined for each component carrier as part of the component carrier configuration. For example, the parameter set configuration may be defined as part of an IE structure, such as pdsch-ConfigDedicated (in downlink) or pucch-ConfigDedicated (in uplink) of the PhysicalConfigDedicated structure used in LTE to specify UE-specific physical channel configurations. For each parameter set configured for the UE PHY, the UE PHY sublayer may make the parameter set configuration visible to the UE MAC. In another alternative, the PHY does not expose the parameter set configuration to the MAC. Instead, the MAC may rely on the priority values ​​of the parameter sets, the logical channel priorities, and the logical channel mapping to the parameter set configuration to perform logical channel multiplexing and scheduling functions.

[0147] In some cases, the MAC scheduler enforces the mapping of bearers to the correct parameter sets, or more specifically, the mapping of logical channels (to which the bearers are mapped) to the correct parameter sets, through appropriate component carrier scheduling (e.g., by ensuring that data from a logical channel or from a data radio bearer is only mapped to component carriers that support only a subset or all of the allowed parameter sets and / or TTIs based on the respective component carrier configuration information in terms of supported parameter sets and / or TTIs). In this example option, the MAC scheduler does not schedule data from a logical channel to an assigned carrier having one or more parameter sets that are not allowed for the logical channel, even if the component carrier is also configured with at least one parameter and / or TTI that is allowed for the logical channel.

[0148] HARQ may be modeled according to various example embodiments. In one example, in the downlink, for each serving cell, there is a HARQ entity in the MAC entity that maintains several parallel HARQ processes. Similarly, in the uplink, for each serving cell with a configured uplink, there may be a HARQ entity in the MAC entity that maintains several parallel HARQ processes, thereby allowing continuous transmission while waiting for HARQ feedback on successful or unsuccessful reception of previous transmissions. The HARQ entity may be common to the network slice. For example, in some cases, the HARQ entity is not specific to the network slice. Data from different network slices may be mapped to the same HARQ entity, and data from the same network slice may be configured on different HARQ entities. The number of parallel HARQ processes for each HARQ entity may be configurable, for example, by RRC signaling. In some cases, the HARQ entity may be configured to support more than one PHY parameter set. For example, data from one HARQ entity may be sent using resources from more than one parameter set. Within the same HARQ entity, data with different PHY parameter sets (e.g., shorter TTI / symbol length due to latency requirements, etc.) may be mapped to different HARQ processes. An example embodiment of such an option is that there is one HARQ entity per component carrier (cell), where each component carrier supports more than one parameter set and / or TTI. The parameter set configuration may be defined for each component carrier as part of the component carrier configuration, e.g., as part of an IE structure such as pdsch-ConfigDedicated (in downlink) or pucch-ConfigDedicated (in uplink) of the PhysicalConfigDedicated structure used in LTE to specify the UE-specific physical channel configuration.

[0149] In another example, for each serving cell with a configured uplink, there is a HARQ entity at the MAC entity for each network slice, which maintains several parallel HARQ processes, allowing continuous transmission while waiting for HARQ feedback on successful or unsuccessful reception of previous transmissions.

[0150] In another example, the HARQ entity is specific to a network slice. For example, data from different network slices may be mapped to different HARQ entities. Each network slice may have more than one HARQ entity. The number of parallel HARQ processes for each HARQ entity may be configurable, for example, via RRC signaling.

[0151] In another example, the HARQ entity is parameter set specific. For example, each HARQ entity may be configured with a specific PHY parameter set, and all data sent from the HARQ entity may utilize the same PHY parameter set. An example embodiment of this option is that there is one HARQ entity per component carrier (cell), where each component carrier is defined using only one parameter and / or TTI.

[0152] In some cases, the HARQ entity is not parameter set specific.The assignment of parameter sets to data sent from the HARQ entity may be dynamic as a result of scheduling decisions.

[0153] In another example HARQ model, a combination of two or more of the above example options is implemented. For example, some HARQ entities may be configured to be network slice-specific, while some other HARQ entities may be configured as common HARQ entities between two or more network slices.

[0154] Based on the above possible models of RB, logical channels, MAC and HARQ, the following embodiments of the NR wireless data link (L2) architecture are now described. It should be understood that although these embodiments are illustrated using the UL L2 structure for illustration, the same concepts can also be applied to the downlink.

[0155] See now Fig.28 , according to an example embodiment, a slice-specific L2 structure is used. Fig.28 An example of a UL L2 structure supporting slice-specific RBs, slice-specific logical channels, and a slice-specific MAC sublayer is described. The example supports configurations in which a common physical resource pool is shared between slices, as well as configurations in which physical resources (i.e., component carriers (CCs) and / or beams) are slice-specific. In this example, see Fig.28, the multi-beam nature of the PHY is exposed to the MAC sublayer. For example, the beam configuration may be known to the MAC sublayer. In some cases, if UL transmission on multiple beams is supported at the UE, a separate HARQ entity may be used for each beam. The beam configuration may also be slice-specific. In one embodiment, the beam configuration may be visible to the MAC, but not specific to the HARQ entity, and all HARQ entities or service cells may share the same beam configuration for each network slice. Alternatively, these details may remain transparent to the MAC sublayer, in which case there may be one HARQ entity per CC, as opposed to one HARQ entity per CC, per beam. In some cases, for the various architecture examples described in this section, alternative examples may also be conceived in which there is one HARQ entity per service cell, regardless of the number of beams used for transmission at the UE or NR node. For example, for the UL data structure, at the UE, there may be one HARQ entity per service cell (component carrier), regardless of the number of transmit beams used by the UE. Fig.29 An example is given in . Similarly, in the DL, in some cases, at the NR node, there may be one HARQ entity per serving cell (component carrier), regardless of the number of transmit beams used by the NR node.

[0156] In some examples, the MAC sublayer is responsible for multiplexing data from logical channels and mapping the resulting transport blocks to the CCs / beams for which the UE has obtained UL grant.

[0157] See now Fig.30 , an example of a UL L2 structure supporting slice-specific RBs and logical channels and a common MAC sublayer is shown. This example can support a configuration in which a common physical resource pool is shared between slices. Fig.30 In the present embodiment shown in , the multi-beam nature of the PHY and the supported parameter sets are exposed to the MAC sublayer. In some cases, if UL transmission on multiple beams is supported at the UE, a separate HARQ entity may be used for each beam. Alternatively, one or both of these characteristics of the PHY may remain transparent to the MAC sublayer. For example, in some cases, there is not one HARQ entity per parameter set, per beam, per CC, but rather one HARQ entity per CC.

[0158] The MAC sublayer may be responsible for multiplexing data from logical channels and mapping the resulting blocks to the CC / beam / parameter set for which the UE has obtained UL authorization.

[0159] See now Fig.31, the L2 structure supports slice-specific RBs, slice-specific logical channels, a common upper MAC layer for scheduling and multiplexing, and slice-specific HARQ. In this example, the UL shared transport channel (or equivalent channel in NR) is slice-specific. For example, a URLL network slice can be mapped to a dedicated HARQ with a transport channel configured along with a PHY channel to meet URLL requirements. There can be more than one slice per CC, so there can be more than one HARQ and more than one associated transmission within a CC.

[0160] Fig.32 The example described in is similar to Fig.31 The example described in , however, the RBs and logical channels are not slice-specific.

[0161] See now Fig.33 , BR and logical channels are slice-specific. MAC including HARQ entity is common to the slices, so they are not slice-specific. This example is similar to Fig.30 , except that transport channels such as the UL transport channel (UL SCH or NR equivalent) are slice-specific. In this model, each HARQ entity may have multiple UL SCHs, for example, one per slice. Transport channels belonging to different slices are associated with different HARQ processes with the HARQ entity.

[0162] See also Fig.34 , the figure shows an example architecture where the L2 structure can be slice-specific, while for some other network slices only the RBs and logical channels are slice-specific.

[0163] Turning now to QoS assurance and bearer mapping, as indicated above, a packet tag may be a tag included in a packet encapsulation header to uniquely associate a data packet characterized by a given traffic flow filter (TFF) or traffic flow filter template with a predetermined matching QoS specification. The packet tag used for packet marking may be, for example, but not limited to, one or more of the following: application ID, flow priority indicator (FPI), QoS flow ID, packet priority indicator (PPI), packet discard priority indicator (PDPI), reflective QoS indication (RQI), or simply any scalar value. The value range of some or all of the packet tags may be specified to allow interoperability between AN and CN nodes.

[0164] See also Fig.35, the figure shows an example flow illustrating control plane signaling for pre-approval of QoS specifications when attaching a UE to a network, in order to accelerate and minimize control plane latency for subsequent service-specific PDU sessions. For illustrative purposes, the CN is decomposed into CN UP functions and CN CP functions. The CN CP functions are further decomposed into CNCP mobility management (MM) and session management (including QoS control) functions, CN CP policy functions, and CN subscription functions. Similar to the EPS / LTE architecture, the CN CP functions may correspond to functions hosted by the S-GW and P-GW. Similarly, the CN CP functions may correspond to functions hosted by, for example, the MME, PCRF, and HSS.

[0165] According to this example, at 1, the OA&M entity configures the CN CP function with supported QoS rules, specifically, the CN CP policy function. The rules may include common QoS rules and network slice-specific rules. The OA&M entity may configure these functions with QoS capabilities that the CN CP and UP functions can support. The configured capabilities may be used, for example, for admission control or traffic regulation. For example, the CNCP may use the configured OA&M capabilities for admission control decisions, and the CN UP may use the configured capabilities for traffic regulation. The capabilities may be common capabilities of network slice-specific capabilities, for example, they may be defined in the form of various system capability metrics (e.g., DL&UL fronthaul bandwidth, DL&UL backhaul bandwidth, maximum CPU usage, etc.) and load metrics (e.g., DL&UL maximum data rate, maximum number of sessions per PDU session type, etc.). An example of a capability may be the total aggregate data rate that can flow through the CN UP function. Similarly, the OA&M entity may configure these functions with QoS capabilities that the AN CP function and the AN UP function can support. The capabilities may be common capabilities of network slice-specific capabilities, for example, they may be defined in the form of various system capability metrics and load metrics. The OA&M entity may also configure the UE with the QoS capabilities that the UE can support (e.g., through the DM OTM process). The capabilities may be common capabilities that are unique to the network slice, for example, they may be defined in the form of various device capability metrics or load metrics. The network node configured with the OA&M configuration parameters may return ACK / NACK to the OA&M entity, i.e., the result of the configuration (success or failure).

[0166] At 2, according to the example, configuration information is exchanged between AN and CN. At 2a, the AN-CN interface application layer configuration data required for the AN CP function and the CN CP function to correctly interoperate on the AN-CN interface is updated to support QoS resource capabilities, such as network slice-specific QoS resource capabilities. In some cases, this process may not affect existing UE-related contexts (if any). The AN CP function can initiate the process. Referring to 2b, in the example, the purpose of "CN Configuration Update (QoS)" to update QoS-related parameters is to update the AN-CN interface application layer configuration data required for the AN CP function and the CN CP function to correctly interoperate on the AN-CN interface to support QoS resource capabilities, such as network slice-specific QoS resource capabilities. In some cases, this process does not affect existing UE-related contexts (if any). The CN CP function can initiate the process.

[0167] Still see Fig.35 According to this example, at 3, the UE initiates a registration / attachment procedure for the network. The UE may include auxiliary information that allows pre-approval of extended QoS for the network during the attachment process. The extended QoS used here may refer to a set of QoS rules required for the service in addition to the QoS rules associated with the default PDU session allowed by the UE subscription. The auxiliary information may be network slice specific, or specific to a service family / use case (e.g., eMBB, URLL, mMTC). The auxiliary information may include information about the UE's usage settings, preferred network behavior, UE capabilities (including network capabilities), (pre-)configured QoS rules, and other configured / installed application information (e.g., application ID and requirements). The attachment process may be the result of polling from the network side (e.g., DM OTA mechanism) in order to pre-configure the UE with approved QoS rules.

[0168] At 4, according to the example, the CN CP function pre-approves a set of QoS rules taking into account UE subscription information, network policy, auxiliary information from the UE and network load. QoS rules may refer to a set of information that enables detection of a service data flow and defines its associated QoS parameters or specifications (including QoS markings). The CN CP may pre-approve QoS rules for multiple service data flows or just packet flows. In some examples, the CN CP configures the CN UP with pre-approved QoS rules.

[0169] At 5, the CN CP notifies the AN CP function of the information of the approved AN-related QoS rules with a signal, so that the corresponding bearer (or L2 data link structure) can be pre-established in the AN. The CN CP provides the AN CP function with the approved QoS specifications and the tags of each specification (NAS-level QoS tags of NAS-level QoS flow ID). As mentioned above, the tags associated with the QoS specifications are used by the CNUP for packet marking. The QoS specification is a combination of all or a subset of QoS parameters. Optionally, the CN CP may also provide the AN CP function with TFTs and their association with QoS specifications. The CN CP may also provide the AN CP function with an identifier that uniquely identifies the data flow within the context of the PDU session. The identifier may identify a single packet flow, or a group of packet flows, such as an SDF. Here, such an identifier may be referred to as a packet flow identifier. The AN CP function may configure the AN UP node with the DRB for the pre-approved packet flow. In some cases, the DRB configuration in the AN UP node may also occur after the configuration of the DRB in the UE. In UP (AN UP and CN UP), an association in the user plane at the Service Access Point (SAP) between the AN UP node (DRB) and the CN UP node (packet flow) may be created.

[0170] Still see Fig.35 , at 6, according to the example, the AN CP node initiates a DRB (pre) establishment to the UE. This can be done, for example, by a procedure similar to the RRC reconfiguration procedure. The AN CP node signals the UE with a tag for each specification (AS-level QoS tag or AS-level QoS flow ID) and the DRB configuration for the approved QoS specification (DL and / or UL). The configuration may also include a packet flow identification for each DRB or a group of DRBs. Fig.36 An example of configuration is shown in . In some examples, in the DL, the UE utilizes the packet flow identifier to identify the matching one or more DRBs so that the received data is routed to the correct SAP of the upper layer. Similarly, in the UL, the UE utilizes the packet flow identifier to identify the matching one or more DRBs so that the received data is routed to the correct DRB for UL transmission. This identification used here can be represented by many terms, such as DRB-Packet Flow Binding ID, DRB-Packet Flow SAP ID, Network Convergence Protocol SAP ID, etc. The details of the association between DRBs and packet flows and the mapping of data packets to DRBs are further discussed below.

[0171] At 7, the UE and the CN CP node exchange the upper layer configuration of the pre-approved QoS rules through NAS signaling, plus direct message transmission through the AN, which may include the approved QoS specifications and the marking of each specification (NAS-level QoS marking of the NAS-level QoS flow ID). The configuration also includes the packet flow identification of each packet flow or a group of packet flows, which is the same packet flow identifier transmitted to the UE AS. At 8, an attachment completion message (or an equivalent message) is sent to the network to indicate the completion of the UE registration. It should be noted that at this time, in some cases, data transmission through the pre-established DRB is not possible. However, if the attachment process includes the establishment of a default packet flow connection, then data transmission may be possible through the default packet flow connection.

[0172] To understand is to carry out Fig.35 The entities of the steps illustrated in the diagram may be logical entities implemented in the form of software (i.e., computer executable instructions) stored in a computer such as Fig.52B and F are shown in the memory of a device or computer system configured for wireless and / or network communication, and run on a processor of the device or computer system. That is, Fig.35 The method illustrated in the figure can be saved in a file such as Fig.52B and F are implemented in the form of software (i.e., computer executable instructions) in a memory of a device such as the device or computer system illustrated in FIG. 1 and F, which, when executed by a processor of the device, performs Fig.35 The steps shown in the diagram are also important to understand. Fig.35 Any sending and receiving steps illustrated in the diagram may be performed by the communication circuitry of the device under the control of the device's processor and computer-executable instructions (eg, software) executed by the processor.

[0173] Now turning to the example of packet flow and DRB activation, see Fig.37 , the example call flow describes the packet flow and C-plane signaling for DRB activation. Fig.37 Steps 1-6 are the same as described above. Fig.35 Same as steps 3-8.

[0174] At 7, a new PDU session establishment or a modification of an existing PDU session is triggered. This may be triggered by the UE (step 7a) or a CN CP node (e.g., a CN CP policy entity, step 7b), or an application server (step 7c), or by the AN (step 7d). For example, if the AN UP node, for example, receives a packet in the UL and detects a packet marking that has no association with a QoS specification within the context of an existing PDU session, the AN may trigger a modification of the PDU session.

[0175] Still see Fig.37 At 8, the CN policy function approves the new QoS rules and notifies the CN CP function for session management and QoS control. The notification to the CP function may include the approved QoS specifications and the associated packet marking to be used in the packet marking performed by the CN UP function. The CN UP is also notified of the approved QoS rules.

[0176] At 9, the CN CP session management and QoS control function then initiates the activation of the pre-established packet flow corresponding to the approved QoS specification to the AN CP node. The CN CP node provides the AN CP node with the packet flow identifier of the pre-established flow to be activated. At this stage, the CN CP node may also initiate the establishment of a packet flow that was not previously approved. For example, if the AN CP node decides to change the marking of a previously pre-established packet flow, the CN may treat it as the establishment of a non-pre-established packet flow. In this case, the CN CP node provides the AN CP node with the approved QoS specification and the marking of each corresponding QoS specification. As described above, the marking associated with the QoS specification is used by the CN UP node for packet marking. Optionally, the CN CP node may also provide TFTs to the AN CP node, as well as their association with the QoS specification. In some cases, the AN CP node performs admission control on the packet flow for which activation or establishment is being requested. For each PDU session, the AN CP node may provide the AN UP node with the DRB ID and the packet flow identifier of the activated pre-approved packet flow. In some examples, the AN CP node also configures the AN UP node with the DRB for the newly established packet flow. For each admitted packet flow, one or more DRBs may be configured. In the UP (AN UP node and CN UP), for the newly established packet flow, i.e., for a packet flow different from the pre-approved packet flow, an association in the user plane at the Service Access Point (SAP) between the AN UP node (DRB) and the CN UP node (packet flow) is created.

[0177] At 10, according to the example, the AN CP node initiates DRB activation to the UE. For each PDU session, the activation message includes the DRB ID and possibly the corresponding packet flow identifier of the DRB to be activated. The AN CP node also signals the UE about the configuration of new DRBs that are not previously pre-established QoS specifications (DL and / or UL) and about the marking of each specification. The configuration also includes the packet flow identification of each DRB or a group of DRBs, see Fig.36An example of configuration. In the DL, the UE utilizes the packet flow identifier to identify the matching one or more DRBs so that the received data is routed to the correct SAP of the upper layer. Similarly, in the UL, the UE utilizes the packet flow identifier to identify the matching one or more DRBs so that the received data is routed to the correct DRB for UL transmission. Although we refer to the DRB and packet flow association identifier as the packet flow identifier, the identifier can be represented by many other terms, such as DRB-packet flow binding ID, DRB-packet flow SAP ID, network convergence protocol SAP ID, etc. The details of the association between DRBs and packet flows and the mapping of data packets to DRBs are discussed below. RRC signaling can be used. In some cases, MAC CE signaling can also be used for DRB activation.

[0178] At 11, the UE sends a DRB activation / new DRB establishment response message to the AN CP node. At 12, the UE sends a NAS direct transfer message to the AN CP node to confirm the activation / new establishment of the packet flow. At 13, the AN CP node relays the UE response message to the CN CP node. At 14, the CN CP node relays the UE response message to the CN UP node. At this step, the following actions may be performed (if not performed before). For example, for each PDU session, the AN CP node may provide the DRB ID and the packet flow identifier of the activated pre-approved packet flow to the AN UP node. The AN CP node may also configure the AN UP node with the DRB for the newly established packet flow. For each admitted packet flow, one or more DRBs may be configured. In the UP (AN UP and CN UP), for the newly established packet flow, that is, for the packet flow different from the pre-approved packet flow, an association in the user plane at the service access point (SAP) between the AN UP node (DRB) and the CNUP node (packet flow) is created. At 15 and 16, the CN CP node relays the UE response message to the CN Policy Function and the Network Application Function if necessary.

[0179] To understand is to carry out Fig.37 The entities of the steps illustrated in the diagram may be logical entities implemented in the form of software (i.e., computer executable instructions) stored in a computer such as Fig.52B and F are shown in the memory of a device or computer system configured for wireless and / or network communication, and run on a processor of the device or computer system. That is, Fig.37 The method illustrated in the figure can be saved in a file such as Fig.52B and F are implemented in the form of software (i.e., computer executable instructions) in a memory of a device such as the device or computer system illustrated in FIG. 1 and F, which, when executed by a processor of the device, performs the Fig.37 The steps shown in the diagram are also important to understand. Fig.37 Any sending and receiving steps illustrated in the diagram may be performed by the communication circuitry of the device under the control of the device's processor and computer-executable instructions (eg, software) executed by the processor.

[0180] Now turning to the association between packet flows and DRBs in the control plane (CP), Fig.38 3 examples are described in . In one example (option 1), there is a static or semi-static binding between a packet flow and a DRB. For example, an AN CP node (e.g., a gNB CP function) configures a DRB or selects a DRB (if configured) that is capable of meeting the QoS specifications of the packet flow that the DRB is being configured or selected to support. The AN CP node binds the DRB to the packet flow. As part of the binding, the AN CP node may instantiate internal user plane protocol stack data structures (downlink and uplink) that link the DRB to the packet flow. In one embodiment, the AN CP node records the association between the DRB, the packet flow identifier, the QoS specification, and the corresponding packet marking to be used for packet marking in the user plane in its binding table (internal memory, database, etc.). In this option, one packet flow (and one marking) is bound to only one DRB. The binding remains valid until the DRB is reconfigured (triggered by the AN CP node, UE, CN, or application server) or the PDU session is reconfigured or changed. In another embodiment, the packet flow can be associated with the tunnel (downlink and uplink) linking the AN UP node and the CN UP node. The packet flow associated with the packet flow identifier is associated with the same tunnel (in the uplink and in the downlink). In this alternative embodiment, the AN CP node binds the DRB and the tunnel (uplink direction and downlink direction). One DRB is bound to only one tunnel (in the uplink and in the downlink).

[0181] For each configured DRB, the AN CP node configures the UE with the corresponding packet flow identifier (see Fig.36 ). The configuration message may be via MAC signaling (e.g., in the case of DRB activation, or via RRC signaling in the case of near DRB establishment). The CN CP node also configures the UE with upper layer (layer above the AS, i.e., NAS) configuration information (e.g., QoS specifications associated with packet flows mapped to the DRB, as well as packet flow identifiers and corresponding QoS markings). The UE uses packet flow identifiers and / or markings to bind the DRB (in uplink and downlink) and the upper layer SAP associated with the packet flows that the DRB is configured to support. As previously mentioned, the term packet flow is generally used here, and a packet flow may refer to a group of packet flows (e.g., service data flows).

[0182] In another example (option 2, Fig.38 ), there is a static / semi-static binding between a packet flow and multiple DRBs. According to this example, the AN CP node configures more than one DRB or selects more than one DRB (if configured), and the more than one DRB is capable of meeting the QoS specifications of the packet flow that the DRB is being configured or selected to support. In contrast to another example (option 3) further described below, the purpose of this option is to provide flexible QoS support without adding additional overhead on the air interface. For example, in the downlink, the AN UP node can dynamically select a DRB for sending a received packet from a set of DRBs that are bound to the packet flow to which the received packet belongs through configuration. The AN CP node can frequently indicate to the AN UP node the DRB to be used among a set of DRBs that are bound to the packet flow through configuration as needed. The AN CP node may make such a decision based on, for example, one or more of the following: overall access network load conditions (which may include radio interface load conditions, fronthaul, backhaul load conditions, and hardware load conditions), service subscription level (e.g., platinum user, gold user, silver user, bronze user, etc.), subscriber profile ID (SPID) parameters of RAT / frequency priority received by the NR node from the CN or from another NR node. Note that the SPID is an index related to user information (e.g., mobility profile, service usage profile). This information is specific to the UE and applies to all its radio bearers.

[0183] In some cases, the AN CP node binds the set of DRBs to a packet flow (in downlink and uplink). As part of the binding, the AN CP node may instantiate an internal user plane protocol stack data structure that links the set of DRBs to the packet flow. In one embodiment, the AN CP node records the association between the set of DRBs, the packet flow identifier, the corresponding QoS specification, and the corresponding packet marking to be used for packet marking in the user plane in its binding table (internal memory, database, etc.). The binding remains valid until the set of DRBs is reconfigured (triggered by the AN CP node, UE, CN, or application server) or the PDU session is reconfigured or changed. In another embodiment, the packet flow may be associated with a tunnel (downlink and uplink) linking the AN UP node and the CN UP node. The packet flow associated with the packet flow identifier is associated with the same tunnel (in uplink and in downlink). In this alternative embodiment, the AN CP node binds the set of DRBs and the tunnel (uplink direction and downlink direction). In some cases, a set of DRBs is bound to only one tunnel (in uplink and in downlink).

[0184] For each set of configured DRBs, the AN CP node configures the UE with the corresponding packet flow identifier (see Fig.36 ). The configuration message may be via MAC signaling (e.g., in the case of DRB activation, or via RRC signaling in the case of near DRB establishment). The CN CP node also configures the UE with upper layer (layer above the AS, i.e., NAS) configuration information (e.g., QoS specifications associated with packet flows mapped to the group of DRBs, as well as packet flow identifiers and corresponding QoS markings). The UE uses the packet flow identifier and / or marking to bind the group of DRBs (in uplink and downlink) and the upper layer SAP associated with the packet flows that the group of DRBs is configured to support. As previously mentioned, the term packet flow is generally used here, and a packet flow may refer to a group of packet flows (e.g., service data flows).

[0185] In another example ( Fig.38 In option 3) in, there is no binding of flows to DRBs. Packets are dynamically mapped to DRBs. For example, in some cases, there is no binding between DRBs and packet flows through configuration in the UE or AN. The behavior of both the NR node and the UE is similar to that described in option 2 in that the selection of the DRB for sending received packets is somewhat dynamic. In the downlink, the AN CP node dynamically selects the DRB for sending and notifies the AN UP node, which then utilizes the DRB until the AN CP node issues a change notification. The AN UP node can also autonomously choose what DRB to use when receiving data packets. Similarly, in the uplink, the UE can dynamically select which DRB to use when receiving data packets from the upper layer of the UE. One of the problems to be solved below is how to route the received packets to the correct upper layer SAP, because there is no configured binding between the DRB and the upper layer SAP.

[0186] Now turn to the mapping of data packets to bearers in the user plane. In the example, it is assumed that by configuring binding DRBs and packet flows, one packet flow is bound to only one DRB, and one DRB is bound to only one packet flow. Two packet flows with different identifiers are bound to different DRBs. With respect to the DL in the AN UP node, in the example, the AN UP node uses the tunnel of the received packet to identify the DRB for sending the received downlink packet. In another embodiment, the AN UP node uses the mark contained in the received packet to identify the DRB for sending the received downlink packet. The AN UP node maps the received packet to the identified DRB for sending. The AN UP node can perform packet marking by including the QoS mark of the sent packet in the packet. With respect to the UL in the AN UP node, in one example, the AN UP node routes the received packet to the CN UP node using the internal binding / association between the DRB data link structure and the tunnel or data link structure associated with the DRB. In another embodiment, the AN UP node uses the mark contained in the received packet to identify the packet flow of the packet and the routing path to the CN UP node. In the case of DL in the UE, in an example, when a packet is received in the downlink, the UE forwards the packet to an upper layer service access point (SAP) associated with the DRB in which the packet was received. In one embodiment, the UE utilizes its internal binding / association between the DRB and the upper layer SAP. In another embodiment, the UE utilizes a tag in the received packet to identify the upper layer SAP associated with the DRB. In the case of UL in the UE, in an example, in the uplink, the UE receives packet data from an upper layer SAP associated with a packet flow identifier. The UE identifies the DRB associated with the SAP, for example from its internal database, in which the mapping between the SAP and the DRB is maintained. The UE transmits the received packet from the upper layer SAP to the PDCP entity (or NR equivalent) associated with the identified DRB. The UE may perform packet marking by including a QoS tag associated with the packet flow identifier in the header of the transmitted packet.

[0187] In another example where there is a static / semi-static binding between a packet flow and multiple DRBs, assume that by configuration binding DRBs and packet flows, one packet flow is bound to a set of DRBs, and a set of DRBs is bound to only one packet flow with one packet flow identifier. Two different sets of DRBs are bound to different packet flows with different packet flow identifiers. During RB establishment (activation of a pre-established bearer or establishment of a new bearer), the AN CP node identifies a set of QoS specifications that can meet the QoS requirements of the packet flow, and binds a set of DRBs matching these QoS specifications to the packet flow.

[0188] This example may allow flexible QoS differentiation, where the DRB for a particular packet may be determined when the packet is received, or at least may vary over time without reconfiguration signaling between the AN CP node and the UE.

[0189] In one embodiment, the AN UP node utilizes the tunnel of the received packet to identify a set of DRBs that can be used to send the received downlink packet. In another embodiment, the AN UP node utilizes the tag contained in the received packet to identify a set of DRBs that can be used to send the received downlink packet.

[0190] The following embodiments may be used to determine a DRB to be used for sending a received packet from a set of DRBs. In one embodiment, an AN CP node (e.g., a gNB in ​​a control plane) may dynamically select a DRB for sending a received packet from a set of DRBs bound to a packet flow by configuration. The AN CP node then notifies the AN UP node of the selected DRB for sending the packet. The AN CP node may make such a decision based on, for example, one or more of the following: overall access network load conditions (which may include radio interface load conditions, fronthaul, backhaul load conditions, and hardware load conditions), service subscription levels (e.g., platinum users, gold users, silver users, bronze users, etc.), subscriber profile ID (SPI) parameters of RAT / frequency priority received by the NR node from the CN or from another NR node. Note that the SPID is an index related to user information (e.g., mobility profile, service usage profile). This information is specific to the UE and applies to all its radio bearers. When triggered from the AN UP node, or periodically triggered in a pre-configured periodicity. The AN UP node may trigger the AN CP node to perform DRB selection, for example, upon packet reception or periodically according to a pre-configured periodicity. In another embodiment, the AN UP node may autonomously and dynamically select a DRB for sending received packets from a set of DRBs that are bound to the packet flow through configuration. The AN UP node maps the received packet to the selected DRB for transmission. The AN UP node may perform packet marking by including the QoS marking of the packet in the transmitted packet.

[0191] In one embodiment, the AN UP node routes the received packet to the CN UP node using the internal binding / association between the DRB data link structure and the tunnel or data link structure associated with the DRB. In another embodiment, the AN UP node uses a tag contained in the received packet to identify the packet flow of the packet and the routing path to the CN UP node. In terms of DL in the UE, when a packet is received in the downlink, the UE forwards the packet to the upper layer service access point (SAP) associated with the DRB that received the packet. In one embodiment, the UE uses its internal binding / association between the DRB and the upper layer SAP. In another embodiment, the UE uses the tag in the received packet to identify the upper layer SAP associated with the DRB. In terms of UL in the UE, in the example, the UE receives packet data from the upper layer SAP associated with the packet flow identifier. The UE identifies a set of DRBs associated with the SAP, for example from its internal database, in which the mapping between the SAP and the DRB is maintained. The UE then selects a DRB from the identified set of DRBs. The UE may select a DRB according to one of the following embodiments. The UE uses the same DRB in the UL as the DRB used for the corresponding downlink packet flow. It should be noted that the DRB can be mapped to a downlink packet flow and an uplink packet flow. The present embodiment assumes that the UE has previously received downlink packets for the same packet flow (i.e., the same packet identifier). In another embodiment, the UE autonomously selects a DRB from an identified set of DRBs. Such a selection may be based on an indication from the AN CP (via RRC signaling or MAC CE signaling). Alternatively, the UE may base its selection on one or more of the following: overall access network load conditions (which may include wireless interface load conditions, fronthaul, backhaul load conditions, and hardware load conditions), service subscription levels (e.g., platinum users, gold users, silver users, bronze users, etc.), operator policies regarding the use of QoS specifications (e.g., based on load estimates and subscription profiles).

[0192] The UE delivers the received packets from the upper layer SAP to the PDCP entity (or NR equivalent) associated with the selected DRB. The UE may perform packet marking by including a QoS marking associated with the packet flow identifier in the header of the transmitted packet.

[0193] In another aspect where there is no binding of streams to DRMs, there is no binding between DRBs and packet streams by configuration, and both the NR node and the UE behave similarly to that described in Option 2 in that the selection of DRBs for sending received packets is dynamic. In the downlink, the NR node dynamically selects the DRB to use when receiving data packets. Similarly, in the uplink, the UE dynamically selects which DRB to use when receiving data packets from upper layers of the UE.

[0194] It is recognized here that one problem to be solved is how to route the received packets to the correct upper layer SAP, since there is no configured binding between the DRB and the upper layer SAP. To solve this problem, in an example described here, a new packet flow encapsulation protocol (FEP) is located above the underlying access layer (AS) SAP (e.g., PDCH or NR equivalent). In some cases, the FEP is below the network / transport layer (e.g., UDP / IP or PDCP / IP in the case of IP data). Although the term flow encapsulation protocol is used here, the term data service adaptation protocol (SDAP) may also be used. Thus, FEP and SDAP may be used interchangeably herein without limitation.

[0195] With respect to the downlink in the AN UP node, in one embodiment, the AN UP node utilizes a tag contained in a received packet to identify and select a QoS specification, and then identifies and selects a DRB that can be used for transmission of the received downlink packet.

[0196] This may allow for flexible QoS differentiation, where the DRB for a particular packet may be determined when the packet is received, or at least may vary over time without reconfiguration signaling between the AN CP node and the UE. Various example mechanisms may be used to determine the QoS specification, and thus, the DRB for the transmission of the received packet. In one example, the AN CP node (e.g., a gNB in ​​the control plane) may dynamically select the QoS specification based on one or more of the following given as examples and not limitations: overall access network load conditions (which may include radio interface load conditions, fronthaul, backhaul load conditions, and hardware load conditions), service subscription levels (e.g., platinum users, gold users, silver users, bronze users, etc.), subscriber profile ID (SPID) parameters of RAT / frequency priority received by the NR node from the CN or from another NR node. The AN CP node may dynamically select the QoS specification based on a trigger from the AN UP node or periodically at a preconfigured periodicity. The AN UP node may, for example, trigger the AN CP node to perform DRB selection at packet reception or periodically at a preconfigured periodicity. In another embodiment, the AN UP node may autonomously and dynamically select a QoS specification, thereby selecting a DRB for transmission of received packets. When selecting a QoS specification, if there is no established DRB with a QoS specification that matches the selected QoS specification, then a new DRB may need to be established. The node that selects the DRB (AN CP node or AN UP node) may trigger the establishment of a new DRB. The AN UP node may trigger the AN CP node to initiate the establishment of a new DRB.

[0197] In some cases, the AN UP node maps the received packets to the selected DRB for transmission. The AN UP node may perform packet marking by including the QoS marking of the packet in the header (FEP header) of the transmitted packet. The AN UP node may also include additional information (e.g., binding identifier, packet flow identifier, etc.) in the packet header to assist in routing the packets in the UE to the correct upper layer service access point (SAP).

[0198] As for the uplink in the AN UP node, according to one example, the AN UP node may utilize information (e.g., QoS marking, binding identifier, packet flow identifier) ​​contained in the header (FEP header) of the received packet to identify the packet flow of the packet and the routing path to the CN UP node. Similar to the downlink case, the AN UP node may autonomously identify the uplink routing path to the CN UP node. Alternatively, the CP CP node may notify the CN UP node of the routing path used to route the received packet to the CN UP. The AN CP node may pre-configure the AN UP node using an association table between the QoS marking (and / or information from the packet header, such as the binding identifier, packet flow identifier) ​​and the routing path. The AN UP node may trigger the AN CP node to obtain information about the association between the routing path and the content of the header of the received packet. The trigger may occur when the packet is received, or may be a periodic request based on a predefined periodicity.

[0199] In the case of a downlink in a UE, in one example, when a packet is received in a downlink, the UE uses a QoS tag included in a header (FEP header) of the received packet to identify an upper layer service access point (SAP) to deliver the received packet. In another embodiment, the UE may use a binding identifier (e.g., a tunnel identifier, a packet flow identifier, etc.) encapsulated in a packet header to identify an upper layer service access point (SAP) to deliver the received packet. In another embodiment, the UE may use a combination of information (e.g., QoS tag, binding identifier, packet flow identifier) ​​in a header of a received packet to identify an upper layer service access point (SAP) to deliver the received packet. In the case where a reflective QoS indicator (RQI) is included in a header of a received packet, a user may associate the information with a QoS specification of a corresponding packet flow.

[0200] In the uplink, in an example, the UE receives packet data from an upper layer SAP associated with a packet flow. The UE identifies the QoS specification (of the packet flow to which the received packet belongs) for the SAP, for example from its internal database. In the case of using RQI, the QoS specification should match the QoS specification of the DL packet flow associated with the UL packet flow. In one embodiment, the UE selects a DRB that can meet the identified QoS. The UE may select the DRB according to one of the following embodiments. In the UL, the UE uses the same DRB as the DRB used for the corresponding downlink packet flow. It should be noted that the DRB can be mapped to a downlink packet flow and an uplink packet flow. This embodiment assumes that the UE has previously received downlink packets for the same packet flow (i.e., the same packet identifier). In another embodiment, the UE autonomously selects a DRB from an identified set of DRBs. Such a selection may be based on an indication from an AN CP node (via RRC signaling or MAC CE signaling). Alternatively, the UE may base its selection on one or more of: overall access network load conditions (which may include radio interface load conditions, fronthaul, backhaul load conditions, and hardware load conditions), service subscription level (e.g., platinum user, gold user, silver user, bronze user, etc.), operator policy on the use of QoS specifications (e.g., based on load estimates and subscription profiles).

[0201] In some cases, the UE delivers received packets from the upper layer SAP to the PDCP entity (or NR equivalent) associated with the selected DRB. The UE may mark packets by including one or more of the following in the packet header of the transmitted packet: a QoS marking associated with a packet flow identifier, a binding identifier, a packet flow identifier.

[0202] Thus, as described above, a device may receive a first data packet, the first data packet including a tag identifying a quality of service specification associated with the data packet. Based on the quality of service specification, the device may select a destination to send the packet, and the device may send the data packet to the destination, wherein the data packet includes the tag. For example, the data packet may be received in a downlink communication in a network, and the destination may include an upper layer service access point of the device. In another example, based on the quality of service specification, the device may select a data radio bearer for sending the packet, thereby selecting a destination. The device may send the data packet to the destination via the selected data radio bearer.

[0203] According to another example, as described above with respect to RQI, a device may receive a first packet in a first direction in a network. The first packet may include a tag identifying a quality of service specification associated with the first packet. Later, the device may receive a second packet in a second direction in the network opposite to the first direction. The device may identify a filter in the second packet and determine that the filter is associated with the tag in the first packet. Based on determining that the filter is associated with the tag, the device may insert the tag into the second packet and send the second packet in the second direction, wherein the first direction is one of an uplink or downlink direction and the second direction is the other of the uplink or downlink directions.

[0204] Turning now to the example of the flow encapsulation protocol, in one example, the RRC controls the FEP configuration. In another example, the functionality of the FEP sublayer is performed by a FEP entity. For a FEP entity configured at an NR node (e.g., gNB), there is a peer PEP entity configured at the UE, and vice versa. In one example, there is one FEP entity in the eNB and one FEP entity in the UE for all UE bearers. In an alternative example, a single FEP entity may be configured for each PDU session. In the case of dual connectivity or multiple connectivity, the UE may be configured with one FEP protocol entity per cell group, the cell group being controlled by a master gNB (MgNB) or a secondary gNB (SgNB). For example, in the case of dual connectivity, where different QoS flows from the same PDU session are mapped to different cell groups, e.g., MgNB and SgNB, the UE may be configured with one FEP entity per session per cell group, i.e., in this case, one FEP entity in the MgNB and one FEP entity in the SgNB for that session.

[0205] In some cases, the FEP entity receives / delivers FEP SDUs to / from upper layers (e.g., UDP / IP or TCP / IP in the UE and CNUP nodes on the network side), and sends / receives FEP PDUs to / from its peer FEP entity over the Uu radio interface or NR equivalent. At the NR node, when the FEP entity receives the FEP SDU from the upper layer, it can construct the corresponding FEP PDU and deliver it to the lower layer. At the UE, when the FEP entity receives the FEP PDU from the lower layer, it can reassemble the corresponding FEP SDU and deliver it to the upper layer. Fig.39 and 40An example overview model of the FEP sublayer in the downlink and uplink, respectively, is illustrated. In the example, the FEP entity delivers / receives the following FEP PDUs to / from the lower layer entities: FEP data PDU. In terms of services provided to upper layers, the FEP may provide delivery of user data plane services to upper layers (e.g., IP). For example, services expected from lower layers (e.g., PDCP) may include delivery of user plane data. The FEP sublayer may support, for example, but not limited to: delivery of user plane data; identification of the packet flow (thus upper layer SAP) to which the FEP SDU belongs; mapping between QoS flows and data radio bearers; and marking of QoS flows in DL and UL packets.

[0206] Turning now to the example FEP operation modes, the FEP entity may be configured with two operation modes: a transparent operation mode (TM) and a non-transparent operation mode (NTM). For example, the TM operation mode may be required for latency-sensitive applications, and for any other use case where the binding between QoS flows and data radio bearers is statically or semi-statically configured (there is no dynamic mapping of packets to data radio bearers as part of packet processing at the access layer in the UE or in the radio access network), or which may be derived implicitly by the receiver. The operation mode may be better understood as the presence or absence of a QoS flow ID or packet marking as broadly defined in this disclosure. In NTM mode, the QoS flow ID or packet marking is present in the FEP header. In one embodiment, the UE may be configured with an operation mode by the gNB through control plane signaling (e.g., RRC signaling). In this case, the UE may be configured with one TM mode entity and one NTM entity per session per cell group. In another embodiment, the use of TM mode or NTM mode is through in-band signaling in the user plane. In this option, the same FEP entity is responsible for both TM and NTM operation modes per session and per cell group. The transmitter of the FEP PDU (gNB in ​​DL and UE in UL) includes an indicator in the FEP header to inform the receiver whether the operation mode is TM mode or NTM.

[0207] In the exemplary transparent operation mode (when the UE is configured with a TM entity), the FEP does not include the FEP header in the FEPPDU.

[0208] In an exemplary transmission operation, when submitting a new transparent mode data (TMD) PDU to a lower layer, the transmitting FEP entity configured as a TM FEP entity submits the FEP SDU as is to the lower layer. In an exemplary reception operation, when receiving a new TMD PDU from a lower layer, the receiving FEP entity configured as a TM FEP entity delivers the TMD PDU as is to an upper layer.

[0209] In some cases, the DL data transmission process is performed by a FEP entity that supports the NTM operation mode or the in-band signaling TM operation mode. In this case, the FEP includes the FEP header in the FEP PDU. In an example reception operation, when a FEP data PDU is received from a lower layer (e.g., PDCP), if the mode indicator indicates the NTM operation mode, the FEP entity in the UE: identifies the upper layer entity to which the FEP SDU is destined based on information contained in the FEP header (e.g., the packet flow ID contained in the FEP header); reassembles the FEP SDU from the FEP data PDU by removing the FEP header from the FEP data PDU; and / or delivers the reassembled FEP SDU to the upper layer entity identified by the packet flow ID. The UE can perform reflective QoS association by updating the uplink QoS specification to the DRB mapping (in the AS) and / or updating the uplink flow filter to the QoS specification mapping (in the NAS). If the mode indicator indicates the TM mode of operation, the UE receiving entity may deliver the TMD PDU to upper layers based on its implicit knowledge of the upper layer SAP.

[0210] In an example transmission operation, when a FEP data SDU is received from an upper layer (e.g., IP), if the mode indicator indicates the NTM operation mode, the FEP entity in the UE may: identify the lower layer entity to which the FEP PDU is destined by performing DRB selection (e.g., performing QoS flow packet to DRB mapping); assemble the FEP PDU by adding a FEP header to the FEP SDU; and / or deliver the assembled PDU to the lower layer entity corresponding to the selected DRB. If the mode indicator indicates the TM operation mode, the UE transmission entity may submit the FEP SDU to the lower layer based on implicit knowledge of the QoS specification / SAP to DRB mapping.

[0211] When a FEP entity receives a FEP PDU containing a reserved value or an invalid value, the FEP entity may discard the received PDU.

[0212] In this example, a FEP PDU is a bit string whose length is byte-aligned (i.e., a multiple of 8 bits). Fig.41In the FEP header, the bit string is represented by a table in which the most significant bit is the leftmost bit of the first row of the table and the least significant bit is the rightmost bit of the last row of the table. More generally, the bit string is read from left to right, so in the order in which the rows are read. The bit order of each parameter field within the FEP PDU is represented by the first most significant bit among the leftmost bits and the last least significant bit among the rightmost bits. The FEP SDU may be a bit string whose length is byte-aligned (i.e., a multiple of 8 bits). Starting from the first bit, the FEP SDU is contained in the FEP PDU. The FEP entity may ignore the value of the reserved bits (if any) in the FEP header.

[0213] The example FEP header may include one or more of the following, given as examples and not by way of limitation: a packet flow identifier, a QoS tag, a binding identifier, one or more reserved bits. In addition, the QoS tag (or marker) may be specific to an AS layer QoS tag, or specific to a NAS layer QoS tag, or may include both an AS layer QoS tag and a NAS layer QoS tag. The presence of an AS QoS tag may be indicated by a single bit, wherein a value of 1 indicates the presence of an AS QoS tag in the FEP header, and a value of 0 indicates the absence of a QoS tag in the FEP header. Similarly, the presence of a NAS QoS tag may be indicated by a single bit, wherein a value of 1 indicates the presence of a NAS QoS tag in the FEP header, and a value of 0 indicates the absence of a NAS QoS tag in the FEP header. The operating mode indicator may be represented by an AS QoS tag bit and / or a NAS QoS tag bit. For example, the UE FEP entity may interpret the reception of an AS QoS marker bit set to 0 and a NAS QoS marker bit set to 0 as TM mode operation.

[0214] Turning now to an example process for supporting UL scheduling, the UL resource grant may be defined in terms of basic physical resource blocks defined in the time-frequency domain, as well as modulation and coding schemes and redundancy version information. The UL grant may also include power control information for UL transmission, and indications / resources for UL ACK / NACK transmission. Since in NR, the UE may provide differentiated QoS by operating on more than one parameter set simultaneously, where the parameter sets may differ in terms of the number of symbols per subframe, subcarrier spacing, TTI, time slot and mini-slot size, the scheduling grant may be a function of the parameter set. The basic unit of a resource grant in the time-frequency domain may be defined as a pair of resource blocks that occupy a duration d in the time domain, which we refer to as l symbols in the following. sThe symbol duration d is the duration of the basic time unit of a subframe and occupies m KHz in the frequency domain subdivided into k subcarriers. The parameters k and / or m can be specific to a parameter set. Alternatively, the parameters k and / or m can be common between multiple parameter sets. Similarly, the symbol duration d s Can be parameter set specific or common across parameter sets. Also, parameter l can be parameter set specific or common across parameter sets. See Parameter l ref ,d ref ,k ref and m ref , define the reference parameter set. ref ,d ref ,k ref and m ref Defined scaling factors, other specified parameter sets can be defined as functions of the reference parameter set.

[0215] The network may assign resource grants to the UE, which are parameter set specific ( Fig.42 ), or non-parameter set specific ( Fig.43 The UE may then split the received non-parameter set specific resource grants into parameter set specific grants and distribute these parameter set specific resources among the logical channels configured for the UE ( Fig.44 ). Regardless of whether the allocated grant is specific to a parameter set or common to more than one parameter set, the grant may explicitly carry one or more transmission specification values. Alternatively, the UE may implicitly derive the transmission specification associated with the grant. One scenario in which the UE may implicitly derive the transmission specification of a resource grant is a scenario in which a cell or component carrier is configured with only one transmission specification. In this case, the UE may know the transmission specification associated with the resource grant allocated on the component carrier without explicit indication from the gNB. Another example of a scenario in which the UE may implicitly derive the transmission specification of a resource grant is a scenario in which a default transmission specification is configured. Such a default transmission specification may be at the UE level, or at the cell or packet carrier level, or at a group of cells or component carriers level. In this scenario, when the UE receives a grant that does not indicate a transmission specification, the UE may derive the transmission specification as the configured default transmission specification.

[0216] With respect to network controlled resource grant allocation, in one example (option 1), the resource / scheduling grant is common to the network slices (i.e., the grant is not specific to a network slice). Data from different network slices may be mapped to the same grant. As an example of this embodiment, the gNB may configure the UE with a resource grant that may be used for the transmission of uplink data from more than one logical channel, at least some of which belong to different network slices. The UE allocates a received grant to the transmission of UL data from logical channels, at least some of which are configured for different network slices. The UE determines the allocation of the received grant relative to the logical channel to which the resource grant is allocated through a logical channel priority handling procedure. The UE may allocate resource grants to logical channels, at least two or more of which belong to different network slices. Within the logical channel priority handling procedure, the UE enforces restrictions on the mapping of logical channels to parameter sets received from the gNB.

[0217] In another example (option 2), the resource / scheduling grant is common to the physical layer (PHY) parameter sets, i.e., the grant is not specific to a PHY parameter set. PHY parameter sets may share the same resource grant. For example, in a UE in the uplink direction, data from more than one parameter set may be mapped to the same resource grant. In this case, data from different PHY parameter sets may be carried on the PHY channel resources in the scheduling grant by utilizing the parameter set parameters / format signaled in the scheduling grant. In an example embodiment, the gNB may allocate to the UE an UL resource grant in the time-frequency domain that is not specific to a parameter set. For example, the grant may be expressed at a granularity level of physical resource blocks as basic time-frequency units defined for a reference parameter set or defined as common to all parameter sets or a subset of parameter sets (see Fig.43 The UE determines the allocation of the received grant relative to the logical channel for which the resource grant is allocated through the logical channel priority processing process ( Fig.44 ). The UE may allocate resource grants to logical channels, where at least two or more logical channels belong to different parameter sets. Within the logical channel priority handling procedure, the UE enforces restrictions on the mapping of logical channels to parameter sets received from the gNB.

[0218] In another example (option 3), resource grants are network slice specific (i.e., data from different network slices are mapped to different grants). In any particular TTI or time interval X, each network slice may have more than one resource grant.

[0219] In another example (option 4), resource grants are parameter set specific (i.e., data from different PHY parameter sets are assigned different resource grants). For example, more than one resource grant may be assigned to each PHY parameter set in a TTI or time interval X as a function of the data flow, service, application, or network slice mapped to the parameter set. In an example embodiment, a UE may be configured to use resources defined by a specific parameter set (see Fig.42 ). The UE allocates the received grant to the logical channel according to the logical channel priority rules. During the logical channel priority processing, the UE excludes from consideration the logical channels that are not allowed to be mapped to the parameter set of the configured resources. In addition, the resource grant can be specific to a logical channel or specific to a logical channel group (option 5). In another example, the resource grant is application-specific (option 6). In another example (option 7), the resource grant is data stream-specific. In another example (option 8), a combination of two or more of the above options is combined. For example, some resource grants may be configured to be network slice-specific, while some other resource grants are configured as common resource grants between two or more network slices.

[0220] NR Resource Authorization Example Option 1

[0221] Now turn to UE-controlled UL resource grant allocation. For option 1, refer to Fig.45 , the resource grant is common to the network slices, i.e., the grant is not specific to a network slice. Data (control plane data or user plane data) generated by different network slices can be mapped to the same grant. In the example, in 1, the UE in this option decides how to distribute the received grants between the network slices, for example, how to allocate the received grants to the logical channels of each network slice. The UE can use a strict priority order between the network slices starting from the highest priority slice to the lowest priority slice (see Fig.45). For example, the network slices are configured with a slice priority order. For example, the network slice with the lowest priority value is the highest priority slice, and the network slice with the highest priority value is the lowest priority slice. The UE may be configured with the network slice configuration by the NR node. One network slice configuration parameter may be a network slice priority. The priority of a network slice may be a function of one or more TTIs configured for a service (e.g., a radio bearer, a logical channel) mapped to the network slice. In the case where more than one TTI is configured for a service, the priority of a network slice may be a function of the minimum TTI among the TTIs configured for the service mapped to the network slice. The priority of a network slice decreases as the TTI value increases, for example, the network slice with the smallest TTI value corresponds to the highest priority network slice, and the network slice with the largest TTI value corresponds to the lowest priority network slice. In this option, network slices are allocated resources in descending order of priority. A network slice with a lower priority will only be allocated resources if any resources remain after the data of a higher priority network slice is allocated resources. Network slices configured with equal priority should receive equal services. Alternatively, in the case of network slices of equal priority, the network with the highest SPBR is selected (as defined in step 3 below). In some cases, the LCP procedure used here is the same as the existing LTE LCP procedure. During the logical channel priority processing, the UE excludes from consideration logical channels that are not allowed to be mapped to the configured resources or network slices that are not allowed to be mapped to the configured resources.

[0222] At 2, following the illustrated example, the UE may utilize a slice-specific SPBR. The UE may be configured by the network with a slice-specific SPBR or a slice-specific PBR for each logical channel. Alternatively, the slice-specific PBR may be derived implicitly by the UE, for example, as the sum of the PBRs of the logical channels of the network slice. In some cases, all network slices are allocated resources in order of decreasing priority (at least for PBR). The MAC entity allocates resources for all data available to be sent on the network slice before satisfying the PBR of lower priority slices. If any resources remain, all network slices are served in strict decreasing priority order until the data for the network slice or the UL grant is exhausted, whichever comes first. Network slices configured with equal priority should receive equal service. Fig.46 The process is highlighted in .

[0223] The network can control the scheduling of uplink data by signaling the following for each network slice: where increasing slice priority values ​​indicate slice priority of lower slice priority levels, slicePrioritisedBitRate setting the slice priority bit rate (SPBR) of the slice, slicebucketSizeDuration setting the slice bucket size duration (SBSD). The bucket size of the slice is equal to SPBR x SBSD. The MAC entity maintains a variable SB for each slice i. i SB i It is initialized to 0 when the first logical channel is established in slice i, and is incremented by the product SPBR for each TTI. i ×TTI duration (applicable to slices), where SPBR i is the preferred bit rate of slice j. The value of SBi must never exceed the bucket size of the slice. If the value of SBi is greater than the bucket size of slice i, then it is set to the bucket size of slice i.

[0224] In an example case where network slice-specific logical channels are envisioned, the logical channels within each slice may be allocated resources in accordance with existing LTE LCP procedures ( Fig.45 Step 3 or Fig.46 Step 3). During the logical channel priority processing, the UE excludes from consideration the logical channels that are not allowed to be mapped to the configured resources or the network slices that are not allowed to be mapped to the configured resources.

[0225] To understand is to carry out Fig.45 and 46 The entities of the steps illustrated in the diagram may be logical entities implemented in the form of software (i.e., computer executable instructions) stored in a computer such as Fig.52B and F are shown in the memory of a device or computer system configured for wireless and / or network communication, and run on a processor of the device or computer system. That is, Fig.45 and 46 The method illustrated in the figure can be saved in a file such as Fig.52B and F are implemented in the form of software (i.e., computer executable instructions) in a memory of a device such as the device or computer system illustrated in FIG. 1 and F, which, when executed by a processor of the device, performs Fig.45 and 46 The steps shown in the diagram are also important to understand. Fig.45 and 46 Any sending and receiving steps illustrated in the diagram may be performed by the communication circuitry of the device under the control of the device's processor and computer-executable instructions (eg, software) executed by the processor.

[0226] NR Resource Authorization Example Option 2

[0227] Assumption: In this option, the resource grant is common to the physical layer (PHY) parameter sets (or TTIs), i.e., the grant is not specific to a PHY parameter set (or to a TTI). PHY parameter sets may share the same resource grant. For example, in a UE in the uplink direction, data from more than one parameter set may be mapped to the same resource grant.

[0228] In the example, the UE decides how to allocate received grants between parameter sets. The UE may use a strict priority order between PHY parameter sets. For example, the PHY parameter sets are configured with a parameter set priority order. For example, the parameter set with the lowest priority value is the highest priority parameter set, and the parameter set with the highest priority value is the lowest priority parameter set. The UE may be configured with a parameter set by the NR node. A parameter set configuration parameter may be a parameter set priority. The priority of a parameter set may be a function of one or more TTIs configured for a service (e.g., a radio bearer, a logical channel) mapped to the parameter set. In the case where more than one TTI is configured for a service, the priority of a parameter set may be a function of the minimum TTI among the TTIs configured for the service mapped to the parameter set. The priority of a parameter set decreases as the TTI value increases, for example, the parameter set with the smallest TTI value corresponds to the highest priority parameter set, and the parameter set with the largest TTI value corresponds to the lowest priority parameter set. In this option, parameter sets are allocated resources in descending order of priority. Resources are allocated to parameter sets of lower priority only if any resources remain after data of higher priority parameter sets are allocated resources. In this case, data of different PHY parameter sets can be carried on the PHY channel resources in the scheduling grant by utilizing the parameter set parameters / format signaled in the scheduling grant. Network slices configured with equal priority should receive equal service. Alternatively, in the case of parameter sets with equal priority, the network with the highest NPBR is selected (as defined in step 3 below). In some cases, the LCP process used here is the same as the existing LTE LCP process. During the logical channel priority processing process, the UE will exclude logical channels that are not allowed to be mapped to the configured resources or parameter sets (e.g., TTIs) that are not allowed to be mapped to the configured resources from consideration. Fig.47 The example procedure is highlighted in .

[0229] In some cases, the UE may utilize a parameter set specific PBR. The UE may be configured with a parameter set specific PBR by the network. Alternatively, the parameter set specific PBR may be derived implicitly by the UE, for example, as the sum of the PBRs of the logical channels of the parameter set. In some cases, all parameter sets are allocated resources in order of decreasing priority (at least for PBR). The MAC entity allocates resources for all data available to be sent on the highest priority parameter set before satisfying the PBRs of lower priority parameter sets. If any resources remain, all parameter sets are served in strict decreasing priority order until the data for the parameter set or the UL grant is exhausted, whichever comes first. Network slices configured with equal priority should be served equally. The network controls the scheduling of uplink data by signaling to the UE the following for each allowed parameter set: where an increasing parameter set priority value indicates a parameter set priority of a lower parameter set priority level, numerologyPrioritisedBitRate sets the priority bit rate (NPBR) of the parameter set, and numerologybucketSizeDuration sets the bucket size duration (NBSD) of the parameter set. The bucket size of the parameter set is equal to NPBR x NBSD. The MAC entity maintains a variable NBi for each parameter set i. NBi is initialized to 0 when parameter set i establishes its first logical channel, and is incremented for each TTI by the product NPBRi x TTI duration (where NPBRi is the priority bit rate of parameter set j). The value of NBi must never exceed the bucket size of the parameter set. If the value of NBi is greater than the bucket size of parameter set i, then it should be set to the bucket size of parameter set i. Fig.48 An example of this process is described in . In the example case where parameter set-specific logical channels are assumed, the logical channels within each parameter set may be allocated resources according to existing LTE LCP procedures. During the logical channel priority processing, the UE excludes from consideration logical channels that are not allowed to map to the configured resources or parameter sets (e.g., TTIs) that are not allowed to map to the configured resources.

[0230] With respect to parameter set priority, the priority of a parameter set may be a function of one or more TTIs configured for a service (e.g., radio bearer, logical channel) mapped to the parameter set. In the case where more than one TTI is configured for a service, the priority of a parameter set may be a function of the minimum TTI among the TTIs configured for the service mapped to the parameter set. The priority of a parameter set decreases with increasing TTI values, e.g., the parameter set with the smallest TTI value corresponds to the highest priority parameter set, while the parameter set with the largest TTI value corresponds to the lowest priority parameter set.

[0231] For example (but not limited to), the priority of parameter sets defined as a function of TTI can be further expressed as follows. In one example, the priority of the parameter set decreases as the value of k2*D(TTI) increases, for example, the parameter set with the smallest k2*D(TTI) value corresponds to the highest priority parameter set, and the parameter set with the largest k2*D(TTI) value corresponds to the lowest priority parameter set. The parameter k2 represents the duration of UL grant to UL data transmission, that is, the duration between the last symbol of UL grant scheduling in TTI n and the corresponding PUSCH transmission TTI n+k2 expressed in units of TTI. The parameter D(TTI) represents the duration of TTI, and D(TTI) can be expressed in microseconds or milliseconds.

[0232] In other examples, the priority of the parameter set decreases as the value of k1*D(TTI) increases, for example, the parameter set with the smallest k1*D(TTI) value corresponds to the highest priority parameter set, and the parameter set with the largest k1*D(TTI) value corresponds to the lowest priority parameter set. Parameter k1 represents the duration of DL data to UL ACK transmission, which can be expressed in units of TTI. In other words, k1 can be defined as follows. Referring to the time slot for PUCCH transmission, if the UE detects a DCI format in the PDCCH that schedules PDSCH reception within a number of symbols within TTI n, then the UE will provide corresponding HARQ-ACK information in the PUCCH transmission within TTI n+k1, where k1 is the number of TTIs, which can be indicated by the [DL-data-DL-acknowledgement] field in the DCI format. The [DL-data-DL-acknowledgement] field value is mapped to the value of the number of time slots defined in the following table (from 3GPP TS 38.213):

[0233] [DL-data-DL-acknowledgement] k '00' The first value of the number of timeslots configured by the higher layer '01' The second value of the number of time slots configured by the higher layer '10' The third value of the number of timeslots configured by the higher layer '11' The fourth value of the number of time slots configured by the higher layer

[0234] In another example, the priority of the parameter set decreases as the value of k3*D(TTI) increases, for example, the parameter set with the smallest k3*D(TTI) value corresponds to the highest priority parameter set, and the parameter set with the largest k3*D(TTI) value corresponds to the lowest priority parameter set. The parameter k3 represents the minimum round trip time (RTT) associated with the parameter set. The RTT can be represented by a function of the TTI, such as k3*TTI. The duration of the RTT can be further represented as k3*D(TTI).

[0235] In some cases, the priority of the parameter set decreases as the value of k4*D(TTI) increases, for example, the parameter set with the smallest k4*D(TTI) value corresponds to the highest priority parameter set, and the parameter set with the largest k4*D(TTI) value corresponds to the lowest priority parameter set. The parameter k2 represents the duration of the DL grant to the DL data reception, that is, the duration in TTIs between the last symbol of the DL grant scheduling in TTI n and the corresponding PDSCH reception TTI n+k4. The parameter D(TTI) represents the duration of the TTI. For example, D(TTI) can be expressed in microseconds or milliseconds.

[0236] NR Resource Authorization Example Option 3:

[0237] Assumption: Resource grants are network slice specific (i.e., data from different network slices are mapped to different grants). In any particular TTI or time interval X, each network slice may have more than one resource grant.

[0238] Here, the UE allocates resources for the data of each network slice according to the grant specific to the network slice. Assuming that the logical channel is specific to the network slice, the existing LTE LCP process can be reused for each network slice. If the logical channel is not specific to the slice, the logical channel can be regarded as specific to the network slice for the purpose of resource allocation (logical channel priority) by the UE. For example, when the data of two or more network slices is mapped to a logical channel, the logical channel can be regarded as specific to the slice with resource grant. If there is more than one such slice with resource grant, the logical channel can be regarded as specific to the slice with the highest priority. If any grant remains, then after the data / logical channel for the slice is allocated resources, the UE (MAC) can use the unused grant of the given slice to allocate resource grants for other network slices. To this end, the UE can regard the unused grant as a public grant and can use any of the resource allocation methods described for the public grant allocation, such as the resource allocation methods of "NR Resource Grant Option 1" or "NR Resource Grant Option 2" above. The UE may allocate unused grants according to predetermined rules or pre-defined rules in the specification. For example, the UE may sequentially allocate unused grants to URLLC data, eMBB data, and then mMTC data.

[0239] In one embodiment, each slice-specific resource grant may be associated with a slice-specific PBR. The UE may be explicitly configured with such a PBR, or the UE may implicitly derive such a slice-specific PBR based on rules specified in the specification or by pre-specification. The UE allocates resources to meet the first slice-specific PBR. If any grants remain, the UE may use the used grants as follows: the use is to allocate grants according to one of the resource allocation methods described in, for example, "NR Resource Grant Option 1" or "NR Resource Grant Option 2" above. The UE may allocate unused grants according to predetermined rules or pre-specified rules in the specification, for example, the UE may sequentially allocate unused grants to URLLC data, eMBB data, and then mMTC data.

[0240] In another embodiment, the UE may reallocate some or all of the resource grants allocated to the network slice by the NR node to another network slice. For example, the UE may autonomously reallocate the resource grants granted by the network to a given network slice to a network slice with a higher priority. For example, the UE may do so according to predetermined rules in the specification or according to rules defined by the network configuration or by pre-determination of the UE. For example, the UE may autonomously reallocate resources associated with the eMBB slice grant to URLLC. Alternatively, the UE may autonomously reallocate resources associated with the URLLC slice grant to eMBB.

[0241] NR Resource Authorization Example Option 4

[0242] Assumption: Resource grants are parameter set specific (i.e., data of different PHY parameter sets are assigned different resource grants). For example, more than one resource grant may be assigned per PHY parameter set in one TTI or time interval X as a function of the data flows, services, applications or network slices mapped to the parameter set.

[0243] In the example, the UE (MAC) allocates resources for data configured to use a given parameter set based on a grant specific to the parameter set. Assuming that the logical channel is specific to the parameter set, the existing LTE LCP process can be reused for various logical channels mapped to the same parameter set. If any grants remain, then after the data / logical channels of the parameter set are allocated resources, the UE (MAC) can use the unused grants of the given parameter set to allocate resource grants for other parameter sets. To this end, the UE can treat the unused grants as public grants and can use any of the resource allocation methods described for public grant allocation, such as the resource allocation methods of "NR Resource Grant Option 1" or "NR Resource Grant Option 2" above. The UE can allocate unused grants according to predetermined rules or pre-defined rules in the specification. For example, the UE can sequentially allocate unused grants to URLLC data, eMBB data, and then mMTC data.

[0244] In one embodiment, each parameter set-specific resource grant may be associated with a parameter set-specific PBR. The UE may be explicitly configured with such a PBR, or the UE may implicitly derive such a slice-specific PBR based on rules specified in the specification or by pre-specification. The UE allocates resources to meet the first parameter set-specific PBR. If any grants remain, then, for example (but not limited to), the UE may use the used grants as follows. The use allocates grants according to one of the described common resource allocation methods (e.g., "NR resource grant option 1" or "NR resource grant option 2" above). The UE may allocate unused grants according to predetermined rules or pre-specified rules in the specification. For example, the UE may sequentially allocate unused grants to URLLC data, eMBB data, and then mMTC data.

[0245] In another embodiment, the UE may reallocate some or all of the resource grants assigned to a parameter set by the NR node to another parameter set. For example, the UE may autonomously reallocate the resource grants granted to a given parameter set by the network to a parameter set with a higher priority. For example, the UE may do so according to a predetermined rule in the specification or according to a rule defined by the network configuration or by pre-determination of the UE.

[0246] NR Resource Authorization Option 5:

[0247] Assumption: Resource grant is specific to a logical channel or specific to a logical channel group. A logical channel group can be one of the following: a logical channel group configured for BSR reporting purposes, a group of logical channels configured to allow the use of the same parameter set or the same TTI value. In the example, the UE allocates resources for data of each logical channel according to the grant specific to the logical channel. If the grant is for a logical channel group, the UE can apply a process similar to the traditional LTE logical channel priority process for resource allocation to logical channels with the same logical channel group. The UE allocates resources to each logical channel in descending order of logical channel priority to meet the PBR. In an alternative embodiment, new priority levels can be defined. For example, such new priority levels can be based on the parameter set / TTI to which the logical channel is configured to be mapped. A logical channel (or a radio bearer associated with a logical channel) can be mapped to more than one parameter set or TTI. In this case, the TTI used to define the priority of the proposed logical channel is the TTI with the largest value among all TTIs for which the logical channel is configured. This priority is an overlay priority on the logical channel priority (e.g., as currently defined in LTE). We denote this new type of priority as logical channel priority type 1 and denote the LTE-like traditional logical channel priority as priority type 2. The UE prioritizes the logical channels as follows: a first sorting based on priority type 1, followed by a second sorting based on priority type 2. The higher the value of priority type 1, the lower the priority of the logical channel, e.g., the higher the TTI value, the lower the priority of the corresponding logical channel. Logical channels with the same priority based on priority type 1 are further sorted according to priority type 2. The higher the value of priority type 2, the lower the priority of the logical channel among the logical channels of the same priority type 1. In some cases, the UE applies the LTE LCP procedure using the logical channel sorting obtained as described above. Fig.49 The above process is illustrated in FIG.

[0248] In some cases, if any resources remain, then all logical channels with data outside the group of logical channels for which the UE received a grant and which are not restricted from using the received resource grant are served in strictly descending priority order until either the data for the logical channel or the UL grant is exhausted, whichever comes first. Logical channels configured with equal priority shall be served equally.

[0249] Instead of step 3 above, if any grant remains, the UE (MAC) may use the unused grant, for example (but not limited to) as follows. The UE may regard the unused grant as a public grant and may use any of the resource allocation methods described for the public grant, such as the resource allocation methods of "NR resource grant option 1" or "NR resource grant option 2" above. The UE may allocate the unused grant according to a predetermined rule or a pre-defined rule in the specification, for example, the UE may sequentially allocate the unused grant to URLLC data, eMBB data, and then mMTC data.

[0250] In another embodiment, logical channel sub-priorities may be defined for applications or data flows mapped to the logical channel. The UE may allocate resources in a strictly descending order of the sub-priorities of the data flows or applications mapped to the logical channel. Alternatively, a PBR may be defined for the data sub-flows or applications mapped to the logical channel. The UE allocates resources to each data flow or application in a descending order of the logical channel sub-priority to meet the sub-priority PBR. If any grants remain, all data flows or applications within the logical channel are served in a strictly descending order of priority until the data or UL grant for the logical channel is exhausted, whichever comes first. Data flows or applications configured with equal logical channel sub-priorities shall be served equally.

[0251] Turning now to enhanced LTE logical channel prioritization, various examples are now given considering the NR resource grant allocation options described above.

[0252] In one embodiment, when a new transmission is made, a logical channel priority handling process is performed. In the example, RRC controls the scheduling of uplink data by signaling the following for each logical channel: wherein the increasing priority value indicates a lower priority level priority, PrioritisedBitRate sets the priority bit rate (PBR), bucketSizeDuration sets the bucket size duration (BSD), and the value of the allowed transmission specification (which indicates whether the data of the logical channel can be sent using authorized resources with the same transmission specification value). For NB-IoT, the corresponding steps of PrioritisedBitRate, bucketSizeDuration, and the logical channel priority handling process (i.e., steps 1 and 2 below) do not apply.

[0253] The MAC entity may maintain a variable Bj for each logical channel j. Bj is initialized to 0 when the associated logical channel is established and is incremented for each TTI by the product PBR × TTI duration, where PBR is the priority bit rate of logical channel j. However, the value of Bj must never exceed the bucket size. If the value of Bj is greater than the bucket size of logical channel j, then it shall be set to the bucket size. The bucket size of a logical channel is equal to PBR × BSD, where PBR and BSD are configured by upper layers.

[0254] In the example, when a new transmission is made, the MAC entity may perform various logical channel priority processing procedures. For example, the MAC entity may allocate resources to logical channels configured with the authorized transmission specifications (or allowed for the authorization) in the following steps. At 1, logical channels with Bj>0 are allocated resources in descending priority order. If the PBR of a logical channel is set to "infinity", the MAC entity shall allocate resources for all data available for transmission on the logical channel before the PBR of a lower priority logical channel is met. At 2, the MAC entity decrements Bj by the total size of the MAC SDUs that served logical channel j in step 1. The value of Bj can be a negative value. At 3, if any resources remain, the logical channels are served in a strictly descending priority order (regardless of the value of Bj) until the data for the logical channel or the UL authorization is exhausted, whichever is exhausted first. Logical channels with the same priority should receive equal service.

[0255] When the MAC entity is requested to send multiple MAC PDUs in one TTI, the above steps 1-3 and the associated rules can be applied to each grant independently or to the sum of the capacities of the grants. In addition, the order in which the grants are processed is determined by the UE implementation. When the MAC entity is requested to send multiple MAC PDUs in one TTI, it is up to the UE implementation to decide in which MAC PDU the MAC control element is included. When the UE is requested to generate MAC PDUs in two MAC entities in one TTI, it is up to the UE implementation to decide in which order the grants are processed. When multiple UL grants are received, the order in which the grants are processed is determined by the UE implementation.

[0256] In another example, RRC controls scheduling of uplink data by signaling, for each logical channel, the following: priority, where the increasing priority value indicates a lower priority level, a prioritisedBitRate that sets the priority bit rate (PBR), a bucketSizeDuration that sets the bucket size duration (BSD), and a value of the allowed transmission specification (which indicates whether the data of the logical channel can be sent using authorized resources with the same transmission specification value). RRC also controls scheduling of uplink data by signaling to the UE the absolute priority of each transmission specification, regardless of their mapping to logical channels, where the increasing priority value indicates a lower priority. For NB-IoT, the corresponding steps of PrioritisedBitRate, bucketSizeDuration, and logical channel priority handling procedures (i.e., steps 1 and 2 below) do not apply.

[0257] The MAC entity maintains a variable Bj for each logical channel j. Bj is initialized to 0 when the associated logical channel is established and is incremented for each TTI by the product PBR × TTI duration, where PBR is the priority bit rate of logical channel j. However, the value of Bj must never exceed the bucket size. If the value of Bj is greater than the bucket size of logical channel j, then it should be set to the bucket size. The bucket size of a logical channel is equal to PBR × BSD, where PBR and BSD are configured by upper layers.

[0258] When a new transmission is performed, the MAC entity may perform the following logical channel priority processing. For each grant, in descending order of priority of the transmission specification, the MAC entity shall, for example, follow the following steps to allocate resources to the logical channels of the transmission specifications configured for the grant. In 1, logical channels with Bj>0 are allocated resources in descending order of priority. If the PBR of a logical channel is set to "infinity", the MAC entity shall allocate resources for all data available for transmission on the logical channel before the PBR of a lower priority logical channel is met. In 2, the MAC entity shall decrement Bj by the total size of the MAC SDU that served logical channel j in step 1. The value of Bj can be a negative value. In 3, if any resources of the current grant remain, the logical channel is served in a strictly descending order of priority (regardless of the value of Bj) until the data for the logical channel or the UL grant is exhausted, whichever is exhausted first. Logical channels configured with the same priority should receive equal service.

[0259] In some cases, when the MAC entity is requested to send multiple MAC PDUs in one TTI, steps 1-3 and the associated rules may be applied to each grant independently, or to the sum of the capacities of the grants. Additionally, the order in which the grants are processed is determined by the UE implementation. When the MAC entity is requested to send multiple MAC PDUs in one TTI, it is up to the UE implementation to decide in which MAC PDU the MAC control element is included. When the UE is requested to generate MAC PDUs in two MAC entities in one TTI, it is up to the UE implementation to decide in which order the grants are processed. When multiple UL grants are received with the same parameter set with priority, the order in which the grants are processed is determined by the UE implementation.

[0260] In another example, RRC controls scheduling of uplink data by signaling, for each logical channel, the following: where the increasing priority value indicates the priority of the lower priority level, the prioritisedBitRate setting the priority bit rate (PBR), the bucketSizeDuration setting the bucket size duration (BSD), the value of the allowed transmission specification (which indicates whether the data of the logical channel can be transmitted using the granted resources with the same transmission specification value), where the increasing priority value indicates the transmission specification-specific priority of the lower priority level. For NB-IoT, the PrioritisedBitRate, bucketSizeDuration, and corresponding steps of the logical channel priority handling process (i.e., steps 1 and 2 below) do not apply.

[0261] The MAC entity maintains a variable Bj for each logical channel j. Bj is initialized to 0 when the associated logical channel is established and is incremented for each TTI by the product PBR × TTI duration, where PBR is the priority bit rate of logical channel j. However, the value of Bj must never exceed the bucket size. If the value of Bj is greater than the bucket size of logical channel j, then it should be set to the bucket size. The bucket size of a logical channel is equal to PBR × BSD, where PBR and BSD are configured by upper layers.

[0262] When a new transmission is made, the MAC entity may perform the following logical channel priority processing. For example, the MAC entity may allocate resources to logical channels configured with the authorized transmission specification (or allowed for the authorization) according to the following steps. At 1, logical channels with Bj>0 are allocated resources in descending priority order. Logical channels configured with the same priority are allocated resources in descending priority order specific to the transmission specification. If the PBR of a logical channel is set to "infinity", the MAC entity shall allocate resources for all data available for transmission on the logical channel before the PBR of a lower priority logical channel is met. At 2, the MAC entity decrements Bj by the total size of the MAC SDU that served logical channel j in step 1. The value of Bj can be a negative value. At 3, if any resources remain, the logical channels are served in a strictly descending priority order (regardless of the value of Bj) until the data for the logical channel or the UL authorization is exhausted, whichever comes first. Logical channels assigned with the same priority shall be served in strictly decreasing order of their transmission size specific priority (regardless of the value of Bj) until the logical channel's data or UL grant is exhausted, whichever comes first. Logical channels assigned with the same transmission size specific priority shall be served equally.

[0263] Note that when the MAC entity is requested to send multiple MAC PDUs in one TTI, steps 1-3 and the associated rules can be applied to each grant independently, or to the sum of the capacities of the grants. Additionally, the order in which the grants are processed is determined by the UE implementation. When the MAC entity is requested to send multiple MAC PDUs in one TTI, it is up to the UE implementation to decide in which MAC PDU the MAC Control element is included. When the UE is requested to generate MAC PDUs in two MAC entities in one TTI, it is up to the UE implementation to decide in which order the grants are processed. Additionally, note that when multiple UL grants are received, the order in which the grants are processed may be determined by the UE implementation.

[0264] In another example, RRC controls scheduling of uplink data by signaling for each logical channel: priority, where an increasing priority value indicates a lower priority level, prioritisedBitRate, which sets a priority bit rate (PBR), bucketSizeDuration, which sets a bucket size duration (BSD), a value of an allowed transmission specification (which indicates whether data of the logical channel can be transmitted using authorized resources with the same transmission specification value), where the increasing priority value indicates a transmission specification-specific priority of the lower priority level. RRC may also control scheduling of uplink data by signaling to the UE the absolute priority of each transmission specification, regardless of their mapping to logical channels, where the increasing priority value indicates a lower priority. For NB-IoT, the corresponding steps of PrioritisedBitRate, bucketSizeDuration, and logical channel priority handling procedures (i.e., steps 1 and 2 below) do not apply.

[0265] The MAC entity may maintain a variable Bj for each logical channel j. Bj is initialized to 0 when the associated logical channel is established and is incremented for each TTI by the product PBR × TTI duration, where PBR is the priority bit rate of logical channel j. However, the value of Bj must never exceed the bucket size. If the value of Bj is greater than the bucket size of logical channel j, then it shall be set to the bucket size. The bucket size of a logical channel is equal to PBR × BSD, where PBR and BSD are configured by upper layers.

[0266] In this embodiment, when a new transmission is performed, the MAC entity may perform the following logical channel priority processing process. For each grant, in descending order of absolute priority of the transmission specification, the MAC entity may, for example, follow the following steps to allocate resources to the logical channel of the transmission specification configured for the grant (or allowed for the grant).

[0267] Step 1: Logical channels with Bj>0 are allocated resources in descending order of priority. Logical channels configured with the same priority are allocated resources in descending order of the logical channel's transmission specification-specific priority. If the PBR of a logical channel is set to "infinity", the MAC entity shall allocate resources for all data available for transmission on the logical channel before satisfying the PBR of a lower priority logical channel. At 2, the MAC entity decrements Bj by the total size of the MAC SDUs that served logical channel j in step 1. The value of Bj can be a negative value. At 3, if any resources remain, the logical channels are served in strictly descending order of priority (regardless of the value of Bj) until the data or UL grant for the logical channel is exhausted, whichever comes first. Logical channels configured with the same priority shall be served in strictly descending order of the logical channel's transmission specification-specific priority (regardless of the value of Bj) until the data or UL grant for the logical channel is exhausted, whichever comes first. Logical channels configured with the same transmission specification-specific priority shall be served equally.

[0268] In some cases, the MAC entity is requested to send multiple MAC PDUs in one TTI. Steps 1-3 and the associated rules may be applied to each grant independently, or to the sum of the capacities of the grants. In addition, the order in which the grants are processed is determined by the UE implementation. When the MAC entity is requested to send multiple MAC PDUs in one TTI, it is up to the UE implementation to decide in which MAC PDU the MAC Control element is included. When the UE is requested to generate MAC PDUs in two MAC entities in one TTI, it is up to the UE implementation to decide in which order the grants are processed.

[0269] In NR, as in LTE, the Transmission Time Interval (TTI) can also be considered as the duration between consecutive data transmission opportunities.

[0270] As illustrated in Table 1, the duration of a slot or mini-slot (e.g., in microseconds) is parameter set specific and thus varies from parameter set to parameter set, but maintains a proportional relationship between parameter sets. There may be more than one mini-slot configuration per parameter set in terms of the number of symbols within a mini-slot. Thus, a mini-slot may have more than one TTI, each TTI having a different duration in milliseconds or microseconds. Assuming that the NR system supports slot-level scheduling and mini-slot-level scheduling, and assuming that the gNB can schedule data transmission with respect to the same UE at the slot level or mini-slot level within the same parameter set or on more than one parameter set, the data transmission timer interval (i.e., the duration between consecutive data transmission opportunities) is variable rather than fixed. In order to have a TTI of fixed duration to support MAC processes such as in LTE, a UE-specific TTI of fixed duration (denoted as TTI) is proposed. *), as the basic NR time unit (NR-UNIT) for MAC procedures. In the remainder of this article, TTI will be used in relation to a fixed basic NR time unit of fixed duration, as opposed to the parameter set-specific variable TTI. * Unless otherwise specified, NR-UNIT and TTI are used here. * Used interchangeably without limitation, the two terms may also simply refer to a predetermined unit of time or a predetermined period of time.

[0271] As a result of the proportional relationship between the durations of symbols, mini-slots or slots in the NR system, the time interval between two consecutive transmission opportunities is also proportional to each other. Assuming slot-level scheduling of the UE, the time interval between two consecutive transmission opportunities must then be a multiple of the smallest of the slot durations that the UE can be configured with. Similarly, assuming mini-slot and slot-level scheduling of the UE, the time interval between two consecutive transmission opportunities will be a multiple of the smallest of the mini-slot durations that the UE can be configured with.

[0272] Thus, NR-UNIT (ie, TTI) can be defined in various ways. * ). For example (but not limited to), NR-UNIT or the predetermined time unit may be defined as:

[0273] According to UE capabilities, for slot-level scheduling (respectively, mini-slot-level scheduling), the minimum of possible slot (respectively, mini-slot) durations that the UE can support. The UE may also take into account other information, such as UE battery level, device category, power saving mode settings, etc.

[0274] • The smallest of the possible slot (respectively, mini-slot) durations among the parameter sets with which the UE is configured. The configuration may be static, or by semi-static RRC signaling.

[0275] • The smallest of the possible slot (respectively, mini-slot) durations among the bandwidth part (BWP) to which the UE is configured. The configuration may be static, or by semi-static RRC signaling.

[0276] The slot (respectively, mini-slot) duration to be used as the minimum time interval between UL transmission opportunities (PUSCH, PUCCH, or either PUSCH or PUCCH) or the minimum time interval between DL reception opportunities (PDSCH, PDCCH, or either PDSCH or PDCCH), signaled by the gNB to the UE.

[0277] The minimum of the slot (respectively, mini-slot) durations obtained over multiple valid parameter sets, where a valid parameter set is defined as an activated parameter set among the configured parameter sets in which the UE may expect UL transmission (PUSCH, PUCCH, or either PUSCH or PUCCH) or DL ​​reception (PDSCH, PDCCH, or either PDSCH or PDCCH). The UE may determine the valid parameter set, i.e., the parameter set in which the UE may expect UL transmission or DL ​​reception, through configuration signaling from the gNB, where the configuration signaling may be one or more of semi-static RRC signaling, MAC signaling (e.g., random access response), or DCI signaling.

[0278] The minimum of the slot (respectively, mini-slot) durations obtained on the activated UL BWP or DL ​​BWP. The UE may be configured with an activated DL BWP by an upper layer parameter [activated-DL-BWP], where the parameter [activated-DL-BWP] defines a subset of DL BWPs in the set of configured DL BWPs for DL ​​reception. Similarly, the UE may be configured with an activated UL BWP by an upper layer parameter [activated-UL-BWP], where the parameter [activated-UL-BWP] defines a subset of UL BWPs in the set of configured UL BWPs for UL transmission.

[0279] • The slot (respectively, mini-slot) duration for the reference or default parameter set.

[0280] Furthermore, NR-UNIT may be defined for UL transmission, or for DL ​​direction.

[0281] For the UL direction, for example (but not limited to), NR-UNIT may be defined as follows:

[0282] According to UE capabilities, for slot-level UL scheduling (respectively, mini-slot-level UL scheduling), the minimum of possible slot (respectively, mini-slot) durations that the UE can support. The UE may also take into account other information, such as UE battery level, device category, power saving mode settings, etc.

[0283] • The smallest of the possible slot (respectively, mini-slot) durations among the UL parameter sets with which the UE is configured. The configuration may be static, or by semi-static RRC signaling.

[0284] • The smallest of the possible slot (respectively, mini-slot) durations among the UL BWPs for which the UE is configured. The configuration may be static, or by semi-static RRC signaling.

[0285] The slot (respectively, mini-slot) duration, signaled by the gNB to the UE, to be used as the minimum time interval between UL transmission opportunities (PUSCH, PUCCH, or either PUSCH or PUCCH).

[0286] The minimum of the slot (respectively, mini-slot) durations obtained over multiple valid UL parameter sets, where a valid UL parameter set is defined as an activated UL parameter set among the configured UL parameter sets in which the UE may expect to perform UL transmissions (PUSCH, PUCCH, or both PUSCH and PUCCH). The UE may determine the valid UL parameter set, i.e., the parameter set in which the UE may expect to perform UL transmissions, through configuration signaling from the gNB, where the configuration signaling may be one or more of semi-static RRC signaling, MAC signaling (e.g., random access response), or DCI signaling.

[0287] The minimum of the slot (respectively, mini-slot) durations obtained on the activated UL BWP. The UE may configure the activated UL BWP by an upper layer parameter [activated-UL-BWP], where the parameter [activated-UL-BWP] defines a subset of the UL BWPs in the set of configured UL BWPs for UL transmission.

[0288] • The slot (respectively, mini-slot) duration of a reference or default parameter set (eg, a reference or default UL parameter set).

[0289] For the DL direction, for example (but not limited to), the NR-UNIT may be defined as follows:

[0290] According to UE capabilities, for slot-level DL scheduling (respectively, mini-slot-level DL scheduling), the minimum of possible slot (respectively, mini-slot) durations that the UE can support. The UE may also take into account other information, such as UE battery level, device category, power saving mode settings, etc.

[0291] • The smallest of the possible slot (respectively, mini-slot) durations among the DL parameter sets with which the UE is configured. The configuration may be static, or by semi-static RRC signaling.

[0292] • The smallest of the possible slot (respectively, mini-slot) durations among the DL BWPs for which the UE is configured. The configuration may be static, or by semi-static RRC signaling.

[0293] The slot (respectively, mini-slot) duration to be used as the minimum time interval between DL reception (PDSCH, PDCCH, or either PDSCH or PDCCH) opportunities, signaled by the gNB to the UE.

[0294] The minimum of the slot (respectively, mini-slot) durations obtained over multiple valid DL parameter sets, where a valid DL parameter set is defined as an activated DL parameter set among the configured DL parameter sets in which the UE may expect DL reception (PDSCH, PDCCH, or either PDSCH or PDCCH). The UE may determine the valid DL parameter set, i.e., the parameter set in which the UE may expect DL transmission, through configuration signaling from the gNB, where the configuration signaling may be one or more of semi-static RRC signaling, MAC signaling (e.g., random access response), or DCI signaling.

[0295] The minimum of the slot (respectively, mini-slot) durations obtained on the activated DL BWP. The UE may configure the activated DL BWP by an upper layer parameter [activated-DL-BWP], where the parameter [activated-DL-BWP] defines a subset of DL BWPs in the set of configured DL BWPs for DL ​​reception.

[0296] • The slot (respectively, mini-slot) duration of a reference or default parameter set (eg, a reference or default DL parameter set).

[0297] Regardless of any NR-UNIT or TTI above * Definition, in some examples, in the UE, NR-UNIT may be represented or configured as an integer number of OFDM symbols. In this case, the duration of the symbol, for example in microseconds or milliseconds, depends on which of the above definitions of NR-UNIT is used.

[0298] For simplicity, in the remainder of this disclosure, unless otherwise specified, NR-UNIT (i.e., TTI * ) is defined independently of the direction of transmission.

[0299] In some cases, the NR-UNIT may be fixed but may be updated over time. For example, if a parameter set or a corresponding BWP with a minimum mini-slot or slot duration is revoked or removed from the set of parameter sets or corresponding BWPs configured for the UE, the NR-UNIT may be updated. Although it is not absolutely necessary to consider the definition of NR-UNIT proposed in this document, such an update may be beneficial, for example in terms of power saving and battery life extension, because the UE will work at a higher time granularity, which means that the UE context, including protocol variables and counters, is updated less frequently.

[0300] Turning now to various example enhancements for LCP, in some cases, the UL resource grant R(i) may be characterized by a UL grant grant time and a duration of the UL grant to UL data transmission (i.e., the total lifetime of the grant). We denote the duration of the UL grant to UL data transmission in the NR_UNIT by k2. In absolute time units, the duration of an NR-UNIT, denoted D(NR-UNIT) in this description, may be expressed in microseconds or milliseconds. Here, the UL grant grant time for the UL grant resource R(i) is understood to be the moment when the grant is received at the UE (e.g., the NR-UNIT number in the common UE-gNB timeline). In the case of an SPS-like UL grant granting scheme consisting of an initial transmission and subsequent periodic transmissions utilizing the same resource grant, the UL grant grant time may also be understood to be the moment of the last UL transmission utilizing the same grant.

[0301] In the example, for a given grant R(i), the maximum processing time budget available to the terminal is a function of the value of k2 (i.e., the total lifetime of the grant) and the applicable timing advance TA (or equivalently, the terminal to base station distance). We denote the maximum processing time budget available to the terminal by T_PROC_UE. The time budget of the LCP process, denoted T_LCP, is a component of T_PROC_UE, with an upper limit of T_PROC_UE. Ideally, in order to minimize the possibility that a new UL grant must be considered in the presence of an ongoing LCP process, T_LCP should be set as small as possible, taking into account the processing capabilities of the UE and the expected UE load. For each grant R(i), a parameter T_LCP(i) can be defined, where T_LCP(i) is the LCP process time budget for processing the grant before the grant lifetime expires. In some examples, T_LCP may be the same for all grants.

[0302] In some examples, the logical channel priority handling process may be applied whenever a new transmission is made. For each available scheduled resource grant R(i), a counter LCP_START(i) is maintained according to an example embodiment. The counter LCP_START(i) may be interpreted as the age of the grant R(i). For each grant R(i), the UE initializes the counter LCP_START(i) to 0 at the UL grant time, and each NR-UNIT thereafter increments the counter LCP_START(i). When for at least one resource grant R(i), the counter LCP_START(j) = k2(j)-T_LCP(j), the UE performs the LCP process. The UE regards all resource grants R(h) that satisfy the relationship T_LCP(j)≥(k2(h)-T_LCP(h))-LCP_START(h) as allowed grants for resource grants to the logical channel. The relationship T_LCP(j)≥(k2(h)-T_LCP(h))-LCP_START(h) implies that the transmission period of data using grant R(j) overlaps with the transmission period of data using grant R(h). In other words, the LCP process triggered by grant R(j) will not be completed before the transmission period of data using grant R(h). Fig.53 Examples are illustrated in Figure 2.

[0303] Fig.54 The first part (Part 1) of an example LCP process is illustrated in FIG. This part of the LCP process corresponds to Fig.53 Follow step 9 in the

[0304] With respect to determining the priority of resource grants, for each resource allowed grant R(h), the UE may determine the priority of the resource grant for the purpose of the LCP procedure based on the remaining lifetime of the grant (i.e., based on the amount of time remaining before the grant lifetime expires). For a grant R(h), at time t, the amount of time remaining before the grant lifetime expires is calculated as k2(h)-LCP_START(h,t), where LCP_START(h,t) is the current value of the counter LCP_START(h) under the NR_UNIT corresponding to time t. For a grant R(j) that satisfies the relationship LCP_START(j)=k2(j)-T_LCP(j) for triggering the LCP procedure, when the LCP is triggered, the remaining lifetime of the grant R(j) is T_LCP(j). The UE prioritizes the allowed grants R(h) in strict descending order of the remaining lifetime values. The grant with the smallest remaining lifetime is the grant with the highest priority, and the grant with the largest remaining lifetime is the grant with the lowest priority.

[0305] In another embodiment, the UE may determine the priority of resource grants based on parameter k2 (i.e., the duration of UL grant to UL data transmission). The UE prioritizes the allowed grants R(h) in a strictly descending order of the values ​​of k2. The grant with the smallest k2 value is the highest priority grant, and the grant with the largest k2 value is the lowest priority grant.

[0306] In the case of a tie, in some cases, the largest grant is selected as the grant with higher priority. The largest grant may be defined as the grant with the largest number of resource elements. Alternatively. The largest grant may be defined as the grant that the UE has estimated can send the maximum amount of data in the MAC SDU. In another alternative, in the case of a tie, a grant with higher priority is randomly selected.

[0307] Turning now to the selection of logical channels, grants can be considered parameter set specific with respect to the LCP procedure. A logical channel can be mapped to more than one parameter set, thus data on a logical channel can be served by more than one parameter set. More than one logical channel can be mapped to more than one parameter set, thus a parameter set specific grant can serve more data from more than one logical channel. Similarly, a logical channel may be restricted to use resource grants on some parameter sets. The LCP procedure should take into account the restrictions on logical channel to parameter set mappings.

[0308] In an example, for each selected UL grant, a logical channel may be selected for the LCP process if the logical channel satisfies various conditions. For example, if the logical channel is not restricted from using the selected grant due to parameter set mapping restrictions (e.g., due to subcarrier spacing (SCS) restrictions), then the logical channel may be selected. In another example, if the logical channel is not restricted from using the selected grant due to data replication restrictions, then the logical channel may be selected. For example, if the DRB is mapped to two logical channels LC1 and LC2 to support data replication on at least two component carriers CC1 and CC2 (CA or DC data replication case), then LC1 may be restricted from using the grant on CC2, and LC2 may be restricted from using the grant on CC1. If the selected grant is on component carrier CC2, then LC1 is restricted from using the selected grant. Similarly, if the selected grant is on CC1, then the logical channel LC2 is restricted from using the selected grant. In another example, the logical channel may be assigned a parameter k2 value. A logical channel may be selected if its k2 value expressed in the NR-UNIT or its duration in microseconds or milliseconds is greater than or equal to the parameter k2 of the selected grant expressed in the same time unit as the parameter k2 of the logical channel. As previously mentioned, the parameter k2 associated with the UL grant represents the duration of the UL grant in the NR-UNIT to the UL data transmission. In absolute time units, the duration of the NR-UNIT, denoted D(NR-UNIT) in this description, may be expressed in microseconds or milliseconds. Here, the UL grant grant time of the UL grant resource R(i) is understood to be the moment when the grant is received at the UE (e.g., the NR-UNIT number in the common UE-gNB timeline). In the case of an SPS-like UL grant granting scheme consisting of an initial transmission and subsequent periodic transmissions using the same resource grant, the UL grant grant time may also be understood to be the moment of the last UL transmission using the same grant.

[0309] An alternative to the above condition may be described as follows: a logical channel may be mapped to one or more parameter sets, i.e., a logical channel may be configured for data transmission using one or more parameter sets. As described earlier in this document, a parameter set may have more than one TTI, each TTI having a different duration in milliseconds or microseconds. Thus, as defined earlier in this document, a logical channel may be configured for data transmission using one or more TTIs. Assuming that the NR system supports slot-level scheduling and mini-slot-level scheduling, and assuming that the gNB may schedule data transmission with respect to the same UE at the slot level or mini-slot level within the same parameter set or on more than one parameter set, the data transmission timer interval (i.e., the duration between consecutive data transmission opportunities) for the data of a given logical channel may be variable rather than fixed. We assume that each logical channel is configured with a parameter k2 that is actually expressed as the number of TTIs. Each TTI for which the logical channel is configured may be converted into a certain number d of NR_UNITs in microseconds or milliseconds. Expressed in fixed duration units, the duration between the UL data grant time and the UL data transmission time may be expressed as k2*d. We use MaxLatency(LCH) to denote the maximum value of k2*d obtained over all TTIs configured for the logical channel LCH. If the MaxLatency value is greater than or equal to the parameter k2 of the selected grant expressed in the same time unit as Maxlatency, then the logical channel LCH is selected. In an alternative embodiment, the acceptable waiting time for the logical channel LCH may be defined as being within a waiting time window characterized by MinLatency(LCH) and MaxLatency(LCH). If the waiting time associated with the grant (i.e., the parameter k2 of the grant) falls within the waiting time window defined by the lower end MinLatency(LCH) and the upper end MaxLatency(LCH), then the logical channel is selected for the grant, i.e., the logical channel is not restricted from using the grant.

[0310] Thus, according to the above description, a device including a plurality of logical channels configured to be connected to a network may receive a first authorization of a resource from a network node connected to the device through the network. The first authorization of the resource may indicate a first lifetime associated with the first authorization, so that when the first lifetime expires, the first authorization is not available. Based on the lifetime associated with the first authorization, the device (UE) may select a logical channel from a plurality of logical channels of the device, and send data through the selected logical channel using the first authorization of the resource. In addition, the first authorization of the resource may also indicate a parameter set associated with the first authorization of the resource, and the selected logical channel may be further selected based on the parameter set. In addition, the device may determine whether a data radio bearer is mapped to more than one logical channel of the plurality of logical channels, and when the data radio bearer is mapped to more than one logical channel of the plurality of logical channels, the device may restrict at least one logical channel of the plurality of logical channels from using the first authorization of the resource.

[0311] Turning now to logical channel priorities, in some cases, the existing LTE logical channel priority definitions can be reused. In this scheme, each logical channel is assigned a priority value. The smaller the priority value, the higher the logical channel priority.

[0312] As already described in the present disclosure, in various examples, a new logical channel priority type may be introduced. In one embodiment, the new priority type may be defined relative to the latency requirements of the service data flows or QoS flows mapped to the logical channel. Each logical channel is assigned a value of the introduced parameter k2. The smaller the value of the parameter k2 assigned to the logical channel, the higher the logical channel priority.

[0313] In an alternative embodiment, the two priority types defined above may be used jointly. For example, a logical channel may be assigned two types of priority, a priority based on parameter k2 and a priority type based on LTE. The logical channels may then be prioritized first based on the priority based on parameter k2. In the event of a tie, in some cases, the logical channels may be prioritized using the logical channel priority according to the traditional LTE priority definition.

[0314] Fig.55 , 56 Different options for the second part (Part 2) of the LCP process are illustrated in Figures 5 and 57. Part 2 of the exemplary LCP process corresponds to Fig.53 Follow step 10 in the previous step.

[0315] In the example, when there is new data to be sent and the LCP process is triggered because the condition LCP_START(j) = k2(j) - T_LCP(j) is satisfied for grant R(j), it is possible that a new grant R(l) becomes available after m NR-UNITs and satisfies the relations T_LCP(j) ≥ m*NR-UNIT and T_LCP(j) - m*NR_UNIT ≥ k2(l) - T_LCP(l), i.e., the LCP process triggered by grant R(j) will not be completed before the start time of grant R(l) processing.

[0316] For this example case where there is at least one common logical channel between the allowed logical channel set of the newly available grant R(l) and the allowed logical channel set of the existing allowed grant R(h), it can be implemented as in Fig.55 and 56 The various options are shown in the diagram.

[0317] In one example, refer to Fig.55 , at 1, the LCP is interrupted. At 2, the grants already allocated by the ongoing LCP are used by the logical channels to which they were allocated. The remaining grants after step 2 may be used in the following step 4. At 3, the newly available grants may be added to the set of allowed grants. At 4, the LCP may be reinitialized, e.g., a new LCP process may be started with a new set of allowed grants, taking into account the remaining resource grants from step 2 plus the newly available grants R(l).

[0318] In another example, refer to Fig.56 , restart the ongoing LCP. For example, at 1, the ongoing LCP is stopped. At 2, according to this example, the resource grants that have been allocated by the LCP process that is now stopped at step 1 are placed back into the pool of grants available for assignment. For example, the values ​​of the allowed grants R(h) may be reset to their corresponding values ​​before the start of the LCP process that is now stopped at step 1. At 3, the newly available grants R(1) may be added to the set of available grants. At 4, the LCP process is restarted using the new set of allowed grants. Alternatively, in view of the fact that the remaining LCP time budget may be insufficient, in some cases two or more parallel LCP processes may be started, each LCP process being assigned a specific non-overlapping set of allowed logical channels.

[0319] When there is no common logical channel between the allowed logical channel set of the newly available grant R(l) and the allowed logical channel set of the existing allowed grant R(h), resource granting can be achieved Fig.57 Another example is shown in the diagram. Fig.57According to the example shown in the diagram, at 1, the ongoing LCP is not interrupted. At 2, a new LCP procedure is started using the set of allowed logical channels specific to the newly allowed grant R(l).

[0320] Thus, in accordance with the above description, a device (UE) including a plurality of logical channels configured to be connected to a network through its communication circuit may receive a first grant of resources from a network node connected to the device through the network, wherein the first grant of resources indicates a first lifetime associated with the first grant, such that the first grant is unusable when the first lifetime expires. Based on the first lifetime associated with the first grant, the device may select a logical channel from a plurality of logical channels of the device and send data through the selected logical channel using the first grant of the resource. In an example, when the first grant of the resource is received, the device may establish a counter associated with the grant. In the case where the first grant is not used, the device may increment the counter each time a predetermined time unit expires to track the age of the first grant. In an example, the device compares the waiting time requirement of each of the plurality of logical channels with the waiting time of the first grant to identify a subset of logical channels that can utilize the grant, wherein the selected logical channel is one of the subset of logical channels. The selected logical channel may be selected from the subset of logical channels based on a predetermined priority of the logical channel, and the predetermined priority may be based on at least one of the waiting time requirement of the selected logical channel or the quality of service requirement of the selected logical channel.

[0321] In addition, as referenced Figure 53-57 The device may receive a second authorization of a resource from a network node connected to the device through a network, wherein the second authorization of the resource indicates a second lifetime associated with the second authorization, so that when the second lifetime expires, the second authorization is unavailable. In an example, the first lifetime of the first authorization overlaps with the second lifetime of the second authorization. The device may determine that the second lifetime will expire before the first lifetime. Based on the determination, the device may use the second authorization of the resource instead of the first authorization of the resource to send data through one of the multiple logical channels. In another example, the device may interrupt the use of the first authorization of the resource to send data through a selected logical channel to use the second authorization of the resource to send data through another logical channel, and after the second authorization of the resource expires, the device may restart sending data through the selected logical channel. In uplink communication, data may be sent by a device (UE) to a network, or in inter-device communication, data may be sent by a device to other devices.

[0322] Turning now to buffer status reporting (BSR), the UE may report the buffer status, ie, the amount of data available for transmission in the UL buffer associated with (one or more) MAC entities, based on various buffer status reporting models.

[0323] In an example buffer status reporting option (option 1), the BSR is common to the network slices, i.e., the buffer status report is not specific to a network slice. In some cases, the buffer status is not reported separately for each network slice. The UE (MAC) may aggregate the buffer status from different network slices and report it as a single buffer status report applicable to the data available for transmission in the UL buffer associated with all network slices. The network may control the buffer status report signaling by configuring the UE with the following example timers common to the network slices, for example using RRC signaling: periodic BSR timer, retransmission BSR timer, and buffer status report prohibition timer. In some examples, the UE may trigger a BSR if any of the following events, given as examples and not limitations, occur: arrival of data, change of serving cell, periodically based on a periodic BSR timer, BSR that replaces MAC PDU padding.

[0324] In another example buffer status reporting option (option 2): the BSR is common to PHY parameter sets. For example, the buffer status report is not specific to a PHY parameter set. In some cases, the buffer status is not reported separately for each parameter set. The UE (MAC) may aggregate the buffer status from different parameter sets and report it as a single buffer status applicable to the data available for transmission in the UL buffer associated with all PHY parameter sets. In an example embodiment, the UE may report the buffer status of a configured logical channel or a group of logical channels without considering the mapping of logical channels to parameter sets. The network may control the buffer status report signaling by configuring the UE with the following timers given as examples and not limitations for all PHY parameter sets using RRC signaling, for example: periodic BSR timer, retransmission BSR timer, and buffer status report prohibition timer. The UE may trigger a BSR if any of the following events occur: arrival of data, change of serving cell, periodically based on the periodic BSR timer, replacing the BSR filled by the MAC PDU.

[0325] In another example buffer status reporting option (option 3): the BSR is network slice specific. For example, the UE (MAC) may report the buffer status from different network slices to the NR node separately for each network slice at the same time. In any particular TTI or time interval X, each network slice may have more than one buffer status report. For example, the UE (MAC) may report the buffer status of different logical channels or different logical channel groups of the network slice separately for each network slice. In another alternative, the UE (MAC) may report a single buffer status for each network slice, that is, the UE may aggregate the buffer status from all logical channels belonging to the same network slice and report it to the NR node as a single buffer status report. The network may control the buffer status report signaling by configuring the UE with the following example timers for each network slice, for example, using RRC signaling as an example and not limitation: periodic BSR timer, retransmission BSR timer, and buffer status report prohibition timer. The UE may trigger a BSR if any of the following events occur, given as examples and not limitations: arrival of data for a network slice, change of serving cell, periodically based on a periodic BSR timer, BSR in place of MAC PDU padding.

[0326] In another example buffer status reporting option (option 4), the BSR is parameter set specific. For example, the UE (MAC) may report buffer status from different parameter sets to the NR node separately for each parameter set at the same time. In any particular TTI or time interval X, each parameter set may have more than one buffer status report. For example, the UE (MAC) may report the buffer status of different logical channels or different logical channel groups of the parameter set separately for each parameter set. In another alternative, the UE (MAC) reports a single buffer status for each parameter set, that is, the UE may aggregate the buffer status from all logical channels belonging to the same PHY parameter set and report it to the NR node as a single buffer status report. The network may control the buffer status report signaling by configuring the UE with the following example timers for each parameter set, for example, using RRC signaling, given as an example and not by way of limitation: a periodic BSR timer, a retransmission BSR timer, and a buffer status report prohibition timer. The UE may trigger a BSR if any of the following events occur, given as examples and not limitations: arrival of data for a network slice, change of serving cell, periodically based on a periodic BSR timer, BSR in place of MAC PDU padding.

[0327] In another example buffer status reporting option (option 5): The BSR is application specific. The UE reports the BSR separately for each application. The network may control the buffer status report signaling by configuring the UE with the following example timers for each application, for example using RRC signaling: periodic BSR timer, retransmission BSR timer, and buffer status report prohibit timer. The UE may trigger a BSR if any of the following events occur, given as examples and not limitations: arrival of data for an application, change of serving cell, periodically based on a periodic BSR timer, BSR that replaces MAC PDU padding.

[0328] In another example buffer status reporting option (option 6): The BSR is data flow specific. The UE reports the BSR separately for each data flow. The network may control the buffer status report signaling by configuring the UE with the following example timers for each data flow, for example using RRC signaling: periodic BSR timer, retransmission BSR timer, and buffer status report prohibit timer. The UE may trigger a BSR if any of the following events occur, given as examples and not limitations: arrival of data for a data flow, change of serving cell, periodically based on a periodic BSR timer, BSR that replaces MAC PDU padding.

[0329] In another example buffer status reporting option (option 7), the BSR is logical channel specific, or logical channel group specific. The UE reports the BSR separately for each logical channel or logical channel group. The logical channel or logical channel group may be slice specific. For example, the BSR may be reported as slice specific, and within each slice, the BSR may be reported on a logical channel basis or on a logical channel group basis, for example, on a slice specific basis or on a slice group basis. The network may control the buffer status report signaling by configuring the UE with the following example timers for each logical channel or logical channel group, for example, using RRC signaling: periodic BSR timer, retransmission BSR timer, and buffer status report prohibition timer. The UE may trigger a BSR if any of the following events, given as examples and not limitations, occur: arrival of data for a logical channel or logical channel group, change of serving cell, periodically based on a periodic BSR timer, instead of a BSR padded with a MAC PDU.

[0330] In another buffer status reporting option (option 8): A combination of two or more of the above options may be performed. For example, the UE may report some buffer status as network-specific buffer status, while the UE may report some other buffer status as common to all network slices.

[0331] UE BSR reporting method and configuration may be configured (by higher layers) to be consistent with UL resource grant allocation. In this way, the network may appropriately utilize the reported BSR to properly determine the uplink scheduling grant(s) for the UE.

[0332] Turning now to power headroom reporting, the UE maximum allowed transmit power may be defined per carrier, per network slice, per beam, etc. Depending on the definition of the UE maximum allowed transmit power, the corresponding power headroom will be defined accordingly. The UE (e.g., MAC) may report power headroom (Type 1 power headroom or Type 2 power headroom), which may be the amount of transmit power available in the UE based on various power status reporting models.

[0333] In an example power headroom reporting option (option 1): PHR is common to network slices, i.e., power headroom reporting is not specific to a network slice. Power headroom is not reported separately for each network slice. The network may control PHR signaling by configuring the UE, for example using RRC signaling, with the following parameters given as examples and not limitations, common to all network slices: periodic PHR timer, inhibit PHR timer, change in path loss (difference between current power headroom and last reported is greater than a configurable threshold).

[0334] In another power headroom reporting option (Option 2): PHR is common to PHY parameter sets, i.e., the power headroom report is not specific to a PHY parameter set. Power headroom is not reported separately for each parameter set. The network may control PHR signaling by configuring the UE, for example, using RRC signaling with the following parameters given as examples and not limitations, common to all PHY parameter sets: periodic PHR timer, inhibit PHR timer, change in path loss (difference between current power headroom and last reported is greater than a configurable threshold).

[0335] In another power headroom reporting option (option 3): PHR is network slice specific, i.e., the UE (MAC) may report the power headroom of different network slices to the NR node separately for each network slice simultaneously. In any specific TTI or time interval X, each network slice may have more than one power headroom report. For example, the UE (MAC) may report the power headroom of different serving cells separately for each network slice. In another alternative, the UE (MAC) may report a single power headroom for each network slice. The network may control PHR signaling by configuring the UE with the following parameters for each network slice, for example, using RRC signaling, given as an example but not as a limitation: periodic PHR timer, prohibition of PHR timer, change in path loss (the difference between the current power headroom and the last report is greater than a configurable threshold).

[0336] In another power headroom reporting option (option 4), the PHR is parameter set specific, i.e., the UE (MAC) may report the power headroom of different PHY parameter sets to the NR node separately for each parameter set simultaneously. In any particular TTI or time interval X, each parameter set may have more than one power headroom report. For example, the UE (MAC) may report the power headroom of different serving cells separately for each parameter set. In another alternative, the UE (MAC) may report a single power headroom for each parameter set. The network may control PHR signaling by configuring the UE with the following parameters for each parameter set, for example, using RRC signaling, given as an example and not as a limitation: periodic PHR timer, prohibit PHR timer, change in path loss (the difference between the current power headroom and the last report is greater than a configurable threshold).

[0337] In another power headroom reporting option (option 5): the power headroom is application specific. The UE reports the power headroom separately for each application. The network can control the PHR signaling by configuring the UE with the following parameters for each application, for example, given as an example and not as a limitation, using RRC signaling: periodic PHR timer, inhibit PHR timer, change in path loss (difference between current power headroom and last report is greater than a configurable threshold).

[0338] In another power headroom reporting option (option 6): PHR is data stream specific. The UE reports PHR for each data stream separately. The network can control PHR signaling by configuring the UE, for example using RRC signaling, with the following parameters for each application given as an example and not limitation: periodic PHR timer, inhibit PHR timer, change in path loss (difference between current power headroom and last report is greater than a configurable threshold).

[0339] In another buffer status reporting option (option 7), a combination of two or more of the above options may be performed. For example, the UE may report some power headrooms as network-specific power headrooms, while the UE may report some other power headrooms common to all network slices, possibly simultaneously.

[0340] Turning now to Scheduling Requests (SR), the UE may send Scheduling Requests (SR) to the NR node based on various example SR models. In one example, the SR is common to the network slices, i.e., the Scheduling Request is not specific to a network slice. Scheduling Requests are not sent separately for each network slice. In some cases, the SR periodicity is common between all slices. The UE may trigger a SR based on the following events given as examples and not limitations: Arrival of data with a higher priority than data already present in the transmit buffer of any configured network slice.

[0341] The SR may be sent as a result of the presence of data available for transmission in a TTI with a higher priority than data already present in the transmit buffer of any configured network slice, but the absence of UL-SCH resources for transmission in that TTI. In one embodiment, the scheduling request may indicate to the gNB the network slice for which resource grant is requested. Each network slice for which resource grant is requested may be indicated by a single bit in the SR. The grant allocation signaled by the gNB to the UE may also include an indication of the network slice for which the grant is allocated. The gNB may set a single bit for each network slice for which a grant is allocated in the grant allocation signaling to the UE, where a "1" indicates that a grant is allocated and a "0" indicates that a grant is not allocated, and vice versa. In another embodiment, the scheduling request does not have an indication of the network slice for which resource grant is requested. When the UE requests resources that are common to network slices (i.e., available to any network slice for which the UE is configured), the UE may not set the slice indication bit in the SR. The UE identifies whether a grant is allocated for each network slice by the value of the bit associated with the network slice in the resource grant message received from the gNB. If the bit is not set for any network slice, the UE may interpret this as the received grant being applicable to all network slices for which the UE is configured.

[0342] In another example of a scheduling request: The SR is common to all PHY parameter sets, i.e., the scheduling request is not specific to a PHY parameter set. Buffer status is not reported separately for each parameter set. Scheduling requests are not sent separately for each parameter set. The SR periodicity is common between all parameter sets. The UE may trigger an SR based on the following event: the arrival of data with a higher priority than data already present in the transmit buffer of any configured parameter set. In one embodiment, the scheduling request may indicate to the gNB the parameter set for which resource grant is requested. Each parameter set for which resource grant is requested may be represented by a single bit in the SR. The grant allocation signaled by the gNB to the UE may also include an indication of the parameter set for which the grant is allocated. The gNB may set a single bit for each parameter set for which a grant is allocated, where "1" indicates that a grant is allocated and "0" indicates that a grant is not allocated, and vice versa. In another embodiment, the scheduling request may not have an indication of the parameter set for which resource grant is requested. When the UE requests resources that are common to parameter sets (i.e., available for any parameter set for which the UE is configured), the UE may not set the parameter set indication bit. In some cases, the UE uses the value of a bit associated with each parameter set in the resource grant message received from the gNB to identify whether a grant is allocated for that particular parameter set. If the bit is not set for any parameter set, the UE may interpret this as the received grant being applicable to all parameter sets for which the UE is configured.

[0343] In another scheduling request option or example, the SR is network slice specific, i.e., the UE may be configured with a network slice specific SR by the gNB, and the UE may send a scheduling request to the NR node separately for each network slice simultaneously. The scheduling periodicity is network slice specific, e.g., for slice x, a scheduling request subframe occurs every n_x subframes, and for slice y, a scheduling request subframe occurs every n_y subframes. The UE may trigger a SR based on the following events given as examples and not limitations: the arrival of data with a higher priority than the data already present in the transmit buffer of the network slice associated with the SR.

[0344] In another example of a scheduling request, the SR is parameter set specific, i.e., the UE may be configured by the gNB with a parameter set specific SR, and the UE may send a scheduling request to the NR node separately for each parameter set, possibly simultaneously. The scheduling periodicity is parameter set specific, e.g., for parameter set x, a scheduling request subframe occurs every n_x subframes, and for parameter set y, a scheduling request subframe occurs every n_y subframes. The UE may trigger a SR based on the following events, given as examples and not limitations: the arrival of data with a higher priority than the data already present in the transmit buffer of the parameter set associated with the SR.

[0345] In another scheduling request example, the SR is application specific, i.e., the UE may be configured with application specific SRs by the gNB, and the UE may send separate SRs for each application simultaneously. The scheduling periodicity is application specific, e.g., for application x, a scheduling request subframe occurs every n_x subframes, and for application y, a scheduling request subframe occurs every n_y subframes. The UE may trigger a SR based on the following events: the arrival of data with a higher priority than the data already present in the transmit buffer of the application associated with the SR.

[0346] In another scheduling request example, the SR is data stream specific, i.e., the UE may be configured with a data stream specific SR by the gNB, and the UE may send a separate SR for each data stream simultaneously. The scheduling periodicity is data stream specific, e.g., for data stream x, a scheduling request subframe occurs every n_x subframes, and for data stream y, a scheduling request subframe occurs every n_y subframes. The UE may trigger a SR based on the following event: the arrival of data with a higher priority than the data already present in the transmit buffer of the data stream associated with the SR.

[0347] In another scheduling request example: the SR is specific to a logical channel, or specific to a logical channel group, i.e., the UE may be configured by the gNB with a logical channel or logical channel group specific SR, and the UE may send a separate SR for each logical channel or logical channel group. The logical channel or logical channel group may be slice specific. For example, the BSR may be reported slice specific, and within each slice, the SR may be reported on a logical channel basis or on a logical channel group basis (e.g., slice specific basis or slice group basis). The UE may trigger an SR based on the following event: the arrival of data with a higher priority than the data already present in the transmit buffer of the logical channel or logical channel group associated with the SR.

[0348] In another scheduling request example, a combination of two or more of the above options. For example, the UE may be able to simultaneously report some SRs that are specific to the network, while the UE may report some other SRs that are common to all network slices.

[0349] Turning now to the example of UE capability coordination between the UE, the access network (e.g., RAN), and the core network, as mentioned above, the next generation mobile telecommunication systems are being designed to support a range of application scenarios such as eMBB, URLLC, and mMTC. These major use cases have different and conflicting service requirements in terms of latency, data rate, mobility, device density, reliability, UE battery life, network energy consumption, etc. In order to effectively support these different and conflicting service requirements, network slicing will be used. It is possible that different UEs have different capabilities in terms of which network slices or combinations of network slices or network slice features they support. The following discusses the UE capability handling method in the context of the next working slice. For this discussion, we will also refer to the slice type as the slice of the primary use case, such as an eMBB slice type, a URLL slice type, or an mMTC slice type.

[0350] UE capabilities may be defined in terms of UE RAN slice capabilities, which may be capabilities such as UE radio capabilities. UE capabilities may also be defined in terms of UE core network slice capabilities. For the UE, one method of UE capability signaling is to signal the RAN slice capabilities to the network based on slice-specific or slice-type-specific basis. Similarly, the UE may signal the UE core network capabilities to the network based on slice-specific or slice-type-specific basis. We may refer to slice-specific capability signaling as network slice hard-segmentation UE capability signaling. In this method, the UE signals the network network slice or network slice type-specific UE capabilities. Another method of network capability signaling is a combined UE capability signaling method. In this method, the UE may signal the network a combined UE RAN capability including UE wireless communications. Similarly, the UE may signal a combined UE core network capability. A third method may be a combination of the two methods, where some UE capabilities (UE RAN / RAT capabilities or UE core network capabilities) are signaled based on slice-specific or slice-type-specific basis, while some other UE capabilities are signaled as combined capabilities between network slices.

[0351] In the example of hard-sliced ​​UE capability handling in network slicing, UE capabilities of a slice or slice type (e.g., radio capabilities such as frequency bands, supported frequency band combinations, core network capabilities such as NAS security algorithms, etc.) may be underutilized, while UE capabilities of another slice or slice type are fully utilized and may benefit from capability expansion or capability upgrade. In such a situation, it may be possible for the network to reallocate UE capabilities from the underutilized slices. The network may reconfigure the UE with a new capability split between network slices or network slice types. The UE may also automatically detect the need to rebalance the capability split between the network slices in which the UE is configured. For example, assume that the UE is configured with a network slice involving an NR RAT. Subsequently, the UE is configured with another slice involving an LTE RAT or a WLAN RAT. This may trigger the UE to initiate a UE capability update to the network (access network and core network) based on its updated capability information (e.g., radio capabilities). For example, this may be the result of the usage level of a particular network slice, or the interference level between RATs (intra-device interference). For example, the UE may send a capability update to the network to indicate, for example, a new frequency band combination or a new capability split between network slices. The network may accept the new capability split or reject and / or propose a new capability split. The UE may initiate the UE capability update procedure in the RRC connected state. The RRC connection state may be any RRC connection state discussed in the NR context, for example, RRC connection active state or RRC connection inactive state.

[0352] An interface, such as a graphical user interface (GUI), may be used to assist a user in controlling and / or configuring functions related to architectural aspects and QoS of the next generation mobile telecommunication system.

[0353] A user interface (UI) may be used to configure one or more of the parameters associated with the invention described herein. The user interface may be textual, a textual user interface (TUI), or graphical, a graphical user interface (GUI).

[0354] The UI may provide the user with the ability to configure how applications / services are mapped to a given set (i.e., slice) of network resources. For example, the UI may allow the user to manually select which slice or slices the application / service can access. Fig.50 An example UI for application / slice mapping is shown in For situations where more than one slice meets the application / service requirements, a list of slices can be provided, where the slices can be sorted according to user preferences.

[0355] For situations where none of the slices detected by the UE can satisfy the service requirements, a notification may be displayed on the UE indicating that the service requirements cannot be satisfied. The user may then be prompted to confirm the indication. Alternatively, the user may be provided with the option to map the application / service to a network slice that can be used to provide a "best effort" service until a slice that can satisfy the service requirements is available. Fig.51 Example signaling between the UI and the modem for this situation is shown in .

[0356] The UI may provide the user with the ability to configure reporting of buffer status reports (BSRs) and / or power headroom reports (PHRs). The UI may provide the user with the ability to set default values ​​for BSR / PHRs or override the values ​​configured by the RRC entity. The UI may also provide the user with the option to select which slice to use for BSR / PHR reporting.

[0357] The UI may provide the user with the ability to configure resource grant allocation options. For example, in the case of network controlled resource grant allocation, the grant allocation may be configured as one of the NR resource grant options; for example, common to the network slice (NR resource grant option 1), common to the physical layer parameter set (NR resource grant option 2), etc. In the case of UE controlled resource grant allocation, the grant allocation may be configured as one of the NR resource grant options; for example, common to the network slice (NR resource grant option 1), common to the physical layer parameter set (NR resource grant option 2), etc. It is to be understood that the NR resource grant allocation may be configured as described below using the NR resource grant allocation method. Fig.52B and the display shown in F, producing Fig.50 interface.

[0358] Example Communication System / network

[0359] The 3rd Generation Partnership Project (3GPP) develops technical standards for cellular telecommunication network technologies, including radio access, core transport networks, and service capabilities - including work on codecs, security, and quality of service. Recent radio access technology (RAT) standards include WCDMA (commonly referred to as 3G), LTE (commonly referred to as 4G), and LTE-Advanced standards. 3GPP has begun work on the standardization of the next generation cellular technology called New Radio (NR) (also referred to as "5G"). 3GPP NR standard development is expected to include the definition of next generation radio access technology (new RAT), which is expected to include the provision of new flexible radio access below 6 GHz, and the provision of new ultra-mobile broadband radio access above 6 GHz. Flexible radio access is expected to consist of new non-backward compatible radio access in new spectrum below 6 GHz, and is expected to include different operating modes that can be multiplexed together in the same spectrum to address a wide range of 3GPP NR use cases with different requirements. Ultra-mobile broadband is expected to include cmWave and mmWave spectrum, which will provide opportunities for ultra-mobile broadband access for indoor applications and hotspots, for example. In particular, ultra-mobile broadband is expected to share a common design framework with sub-6 GHz flexible wireless access, with cmWave and mmWave-specific design optimizations.

[0360] 3GPP has identified a variety of use cases that NR is expected to support, resulting in a wide variety of user experience requirements for data rates, latency, and mobility. Use cases include the following general categories: enhanced mobile bandwidth (e.g., broadband access in dense areas, ultra-high broadband access indoors, broadband access in crowds, 50+Mbps everywhere, ultra-low-cost broadband access, mobile broadband in vehicles), emergency communications, massive machine-type communications, network operations (e.g., network slicing, routing, migration and interworking, energy saving), and enhanced vehicle-to-everything (eV2X) communications. Specific services and applications in these categories include, for example, surveillance and sensor networks, device remote control, two-way remote control, personal cloud computing, video streaming, wireless cloud office, first responder connectivity, car emergency calls, disaster alerts, real-time gaming, multiple video calls, autonomous driving, augmented reality, tactile Internet, and virtual reality, to name a few. All of these and other use cases are contemplated herein.

[0361] Fig.52AThe diagram illustrates one embodiment of an example communication system 100 in which the methods and apparatus described and claimed herein may be embodied. As shown, the example communication system 100 may include wireless transmit / receive units (WTRUs) 102a, 102b, 102c, and / or 102d (which may be generally or collectively referred to as WTRUs 102), a radio access network (RAN) 103 / 104 / 105 / 103b / 104b / 105b, a core network 106 / 107 / 109, a public switched telephone network (PSTN) 108, the Internet 110, and other networks 112, although it will be appreciated that the disclosed embodiments contemplate any number of WTRUs, base stations, networks, and / or network elements. Each WTRU 102a, 102b, 102c, 102d may be any type of device or apparatus configured to operate and / or communicate in a wireless environment. Although in the Figures 52A-52E In the figures, each WTRU 102a, 102b, 102c, 102d is described as a handheld wireless communication device, but it is to be understood that for the various use cases envisioned for 5G wireless communications, each WTRU may include or be embodied in any type of device or apparatus configured to send and / or receive wireless signals, including, by way of example only, a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a smart phone, a laptop, a tablet, a netbook, a notebook computer, a personal computer, a wireless sensor, a consumer electronic product, a wearable device such as a smart watch or smart clothing, a medical or e-health device, a robot, an industrial equipment, a drone, a vehicle such as a car, truck, train or airplane, and the like.

[0362] The communication system 100 may also include a base station 114a and a base station 114b. The base station 114a may be any type of device configured to wirelessly interface with at least one of the WTRUs 102a, 102b, 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The base station 114b may be any type of device configured to wiredly and / or wirelessly interface with at least one of the RRHs (remote radio heads) 118a, 118b and / or TRPs (transmit and receive points) 119a, 119b to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The RRHs 118a, 118b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102c to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. The TRPs 119a, 119b may be any type of device configured to wirelessly interface with at least one of the WTRUs 102d to facilitate access to one or more communication networks, such as the core network 106 / 107 / 109, the Internet 110, and / or other networks 112. For example, the base stations 114a, 114b may be base transceiver stations (BTS), Node-Bs, eNode Bs, Home Node Bs, Home eNode Bs, site controllers, access points (APs), wireless routers, and the like. Although the base stations 114a, 114b are depicted as single elements, it is appreciated that the base stations 114a, 114b may include any number of interconnected base stations and / or network elements.

[0363] The base station 114a may be part of the RAN 103 / 104 / 105, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114b may be part of the RAN 103b / 104b / 105b, which may also include other base stations and / or network elements (not shown), such as a base station controller (BSC), a radio network controller (RNC), a relay node, etc. The base station 114a may be configured to send and / or receive wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The base station 114b may be configured to send and / or receive wired and / or wireless signals within a specific geographic area, which may be referred to as a cell (not shown). The cell may be further divided into cell sectors. For example, the cell associated with the base station 114a may be divided into three sectors. Thus, in an embodiment, the base station 114a may include three transceivers, for example, one transceiver for each sector of the cell. In an embodiment, the base station 114a may employ multiple-input multiple-output (MIMO) technology and may use multiple transceivers for each sector of the cell.

[0364] The base station 114a may communicate with one or more of the WTRUs 102a, 102b, 102c via an air interface 115 / 116 / 117, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115 / 116 / 117 may be established using any suitable radio access technology (RAT).

[0365] The base station 114b may communicate with one or more of the RRHs 118a, 118b and / or TRPs 119a, 119b via a wired interface or air interface 115b / 116b / 117b, which may be any suitable wired link (e.g., cable, optical fiber, etc.) or a wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115b / 116b / 117b may be established using any suitable radio access technology (RAT).

[0366] The RRHs 118a, 118b and / or the TRPs 119a, 119b may communicate with one or more of the WTRUs 102c, 102d via an air interface 115c / 116c / 117c, which may be any suitable wireless communication link (e.g., radio frequency (RF), microwave, infrared (IR), ultraviolet (UV), visible light, cmWave, mmWave, etc.). The air interface 115c / 116c / 117c may be established using any suitable radio access technology (RAT).

[0367] More specifically, as described above, the communication system 100 may be a multiple access system and may use one or more channel access methods, such as CDMA, TDMA, FDMA, OFDMA, SC-FDMA, etc. For example, the base station 114a and the WTRUs 102a, 102b, 102c in the RAN 103 / 104 / 105, or the RRHs 118a, 118b and the TRPs 119a, 119b and the WTRUs 102c, 102d in the RAN 103b / 104b / 105b, may implement a radio technology such as Universal Mobile Telecommunications System (UMTS) Terrestrial Radio Access (UTRA), and UTRA may use Wideband CDMA (WCDMA) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. WCDMA may include communication protocols such as High Speed ​​Packet Access (HSPA) and / or Evolved HSPA (HSPA+). HSPA may include High Speed ​​Downlink Packet Access (HSDPA) and / or High Speed ​​Uplink Packet Access (HSUPA).

[0368] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b and TRPs 119a, 119b and the WTRUs 102c, 102d in the RAN 103b / 104b / 105b may implement a radio technology such as Evolved UMTS Terrestrial Radio Access (E-UTRA), which may utilize Long Term Evolution (LTE) and / or LTE-Advanced (LTE-A) to establish the air interface 115 / 116 / 117 or 115c / 116c / 117c, respectively. In the future, the air interface 115 / 116 / 117 may implement 3GPP NR technology.

[0369] In an embodiment, the base station 114a and the WTRUs 102a, 102b, 102c, or the RRHs 118a, 118b and TRPs 119a, 119b and the WTRUs 102c, 102d in the RAN 103b / 104b / 105b may implement a wireless technology such as IEEE 802.16 (e.g., Worldwide Interoperability for Microwave Access (WiMAX)), CDMA2000, CDMA2000 1X, CDMA2000 EV-DO, Interim Standard 2000 (IS-2000), Interim Standard 95 (IS-95), Interim Standard 856 (IS-856), Global System for Mobile Communications (GSM), Enhanced Data Rates for GSM Evolution (EDGE), and GSM EDGE (GERAN).

[0370] Fig.52A The base station 114c in the example may be, for example, a wireless router, a Home Node B, a Home eNode B, or an access point, and may utilize any appropriate RAT to facilitate wireless connectivity in a local area, such as a business location, a home, a vehicle, a campus, and the like. In an embodiment, the base station 114c and the WTRU 102e may implement wireless technologies such as IEEE 802.11 to establish a wireless local area network (WLAN). In an embodiment, the base station 114c and the WTRU 102d may implement wireless technologies such as IEEE 802.15 to establish a wireless personal area network (WPAN). In another embodiment, the base station 114c and the WTRU 102e may utilize a cellular-based RAT (e.g., WCDMA, CDMA2000, GSM, LTE, LTE-A, etc.) to establish a pico cell or a femto cell. Fig.52A As shown in FIG, base station 114b may be directly connected to Internet 110. Thus, base station 114c may not be required to access Internet 110 via core network 106 / 107 / 109.

[0371] The RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b may be in communication with a core network 106 / 107 / 109, which may be any type of network configured to provide voice, data, applications, and / or Voice over Internet Protocol (VoIP) services to one or more of the WTRUs 102a, 102b, 102c, 102d. For example, the core network 106 / 107 / 109 may provide call control, billing services, mobile location-based services, pre-paid calling, Internet connectivity, video distribution, etc., and / or perform high-level security functions such as user authentication.

[0372] Although not in Fig.52A105b and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105b, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with other RANs (not shown) that employ a GSM radio technology.

[0373] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d, 102e to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a circuit-switched telephone network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer networks and devices that utilize common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include another core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 and / or the RAN 103b / 104b / 105 or a different RAT.

[0374] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d, and 102e may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig.52A The WTRU 102e shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114c, which may employ an IEEE 802 radio technology.

[0375] Fig.52B 1 is a block diagram of an example device or apparatus (e.g., WTRU 102) configured for wireless communication according to embodiments illustrated herein. Fig.52BAs shown in , the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136, and other peripherals 138. It is to be appreciated that the WTRU 102 may include any sub-combination of the above elements while still being consistent with the embodiment. In addition, the embodiment contemplates that the base stations 114a and 114b, and / or the nodes that the base stations 114a and 114b may represent, such as (but not limited to) base transceiver stations (BTS), Node-B, site controllers, access points (APs), home node-Bs, evolved home node-Bs (eNodeBs), home evolved node-Bs (HeNBs), home evolved node-B gateways, and proxy nodes, etc. may include Fig.52B Some or all of the elements described in and illustrated herein.

[0376] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Fig.52B The processor 118 and the transceiver 120 are depicted as separate components, although it is appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0377] The transmit / receive element 122 may be configured to transmit or receive signals to or from a base station (e.g., base station 114a) via the air interface 115 / 116 / 117. For example, in an embodiment, the transmit / receive element 122 may be an antenna configured to transmit and / or receive RF signals. Fig.52A Although not shown in the figure, it will be appreciated that the RAN 103 / 104 / 105 and / or the core network 106 / 107 / 109 may be in direct or indirect communication with other RANs that employ the same RAT as the RAN 103 / 104 / 105 or a different RAT. For example, in addition to being connected to the RAN 103 / 104 / 105, which may utilize an E-UTRA radio technology, the core network 106 / 107 / 109 may also be in communication with another RAN (not shown) that employs a GSM radio technology.

[0378] The core network 106 / 107 / 109 may also serve as a gateway for the WTRUs 102a, 102b, 102c, 102d to access the PSTN 108, the Internet 110, and / or other networks 112. The PSTN 108 may include a line-switched circuit network that provides plain old telephone service (POTS). The Internet 110 may include a global system of interconnected computer systems and devices that utilize common communication protocols, such as the Transmission Control Protocol (TCP), the User Datagram Protocol (UDP), and the Internet Protocol (IP) in the TCP / IP Internet protocol suite. The networks 112 may include wired or wireless communication networks owned and / or operated by other service providers. For example, the networks 112 may include an additional core network connected to one or more RANs, which may employ the same RAT as the RAN 103 / 104 / 105 or a different RAT.

[0379] Some or all of the WTRUs 102a, 102b, 102c, 102d in the communication system 100 may include multi-mode capabilities. For example, the WTRUs 102a, 102b, 102c, 102d may include multiple transceivers for communicating with different wireless networks via different wireless links. Fig.52A The WTRU 102c shown in FIG. 1 may be configured to communicate with the base station 114a, which may employ a cellular-based radio technology, and with the base station 114b, which may employ an IEEE 802 radio technology.

[0380] Fig.52B 1 is a block diagram of an example device or apparatus, such as WTRU 102, configured for wireless communication according to embodiments illustrated herein. Fig.52B As shown in , the example WTRU 102 may include a processor 118, a transceiver 120, a transmit / receive element 122, a speaker / microphone 124, a keypad 126, a display / touchpad / indicator 128, a non-removable memory 130, a removable memory 132, a power supply 134, a global positioning system (GPS) chipset 136 and other peripherals 138. It is to be appreciated that the WTRU 102 may include any sub-combination of the above elements while still being consistent with the embodiment. In addition, the embodiment contemplates that the base stations 114a and 114b, and / or the nodes that the base stations 114a and 114b may represent, such as (but not limited to) base transceiver stations (BTS), Node-B, site controllers, access points (APs), home node-Bs, evolved home node-Bs (eNodeBs), home evolved node-Bs (HeNBs), home evolved node-B gateways and proxy nodes, etc. may include Fig.52B Some or all of the elements described in and illustrated herein.

[0381] The processor 118 may be a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 118 may perform signal coding, data processing, power control, input / output processing, and / or any other functionality that enables the WTRU 102 to operate in a wireless environment. The processor 118 may be coupled to the transceiver 120, which may be coupled to the transmit / receive element 122. Although Fig.52B The processor 118 and the transceiver 120 are depicted as separate components, although it is appreciated that the processor 118 and the transceiver 120 may be integrated together in an electronic package or chip.

[0382] The send / receive element 122 may be configured to send or receive signals to and from a base station (e.g., base station 114a) via an air interface 115 / 116 / 117. For example, in an embodiment, the send / receive element 122 may be an antenna configured to send and / or receive RF signals. In an embodiment, the send / receive element 122 may be a transmitter / detector configured to send and / or receive, for example, IR, UV, or visible light signals. In another embodiment, the send / receive element 122 may be configured to send and receive both RF signals and optical signals. It is to be appreciated that the send / receive element 122 may be configured to send and / or receive any combination of wireless signals.

[0383] In addition, although the transmit / receive element 122 is Fig.52B Although described as a single element in the WTRU 102, the WTRU 102 may include any number of transmit / receive elements 122. More specifically, the WTRU 102 may employ MIMO technology. Thus, in an embodiment, the WTRU 102 may include two or more transmit / receive elements 122 (e.g., multiple antennas) for transmitting and receiving wireless signals over the air interface 115 / 116 / 117.

[0384] The transceiver 120 may be configured to modulate signals to be transmitted by the transmit / receive element 122 and to demodulate signals received by the transmit / receive element 122. As described above, the WTRU 102 may have multi-mode capabilities. Thus, the transceiver 120 may include multiple transceivers that enable the WTRU 102 to communicate over multiple RATs, such as UTRA and IEEE 802.11.

[0385] The processor 118 of the WTRU 102 may be coupled to a speaker / microphone 124, a keypad 126, and / or a display / touchpad / indicator 128 (e.g., a liquid crystal display (LCD) display unit or an organic light emitting diode (OLED) display unit), and may receive user input data therefrom. The processor 118 may also output user data to the speaker / microphone 124, the keypad 126, and / or the display / touchpad / indicator 128. In addition, the processor 118 may access information from and store data in any type of suitable memory, such as a non-removable memory 130 and / or a removable memory 132. The non-removable memory 130 may include a random access memory (RAM), a read-only memory (ROM), a hard disk, or any other type of storage device. The removable memory 132 may include a subscriber identity module (SIM) card, a memory stick, a secure data (SD) memory card, or the like. In an embodiment, the processor 118 may access information from, and store data in, memory that is not physically located on the WTRU 102, such as on a server or a home computer (not shown).

[0386] The processor 118 may receive power from the power source 134 and may be configured to distribute power to and / or control power to the other components in the WTRU 102. The power source 134 may be any suitable device for providing power to the WTRU 102. For example, the power source 134 may include one or more dry cell batteries, solar cells, fuel cells, etc.

[0387] The processor 118 may also be coupled to the GPS chipset 136, which may be configured to provide location information (e.g., longitude and latitude) regarding the current location of the WTRU 102. The WTRU 102 may receive location information from a base station (e.g., base stations 114a, 114b) over the air interface 115 / 116 / 117 in addition to or in lieu of the information from the GPS chipset 136, and / or determine its location based on the timing of receiving signals from two or more nearby base stations. It will be appreciated that the WTRU 102 may acquire location information using any suitable location-determination method while still being consistent with an embodiment.

[0388] The processor 118 may be further coupled to other peripherals 138, which may include one or more software and / or hardware modules that provide additional features, functionality, and / or wired or wireless connectivity. For example, the peripherals 138 may include various sensors such as accelerometers, biometric (e.g., fingerprint) sensors, electronic compasses, satellite transceivers, digital cameras (for photos or videos), universal serial bus (USB) ports or other interconnect interfaces, vibration devices, television transceivers, hands-free headsets, modules, FM radio units, digital music players, media players, video game player modules, internet browsers, etc.

[0389] The WTRU 102 may be embodied in other devices or apparatuses, such as sensors, consumer electronics, wearable devices such as smart watches or smart clothing, medical or e-health devices, robots, industrial equipment, drones, vehicles such as cars, trucks, trains, or airplanes. The WTRU 102 may be connected to other components, modules, or systems of such devices or apparatuses through one or more interconnect interfaces, such as an interconnect interface that may include one of the peripherals 138.

[0390] Fig.52C 1 is a system diagram of the RAN 103 and the core network 106 according to an embodiment. As described above, the RAN 103 may employ UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 115. The RAN 103 may also communicate with the core network 106. Fig.52C As shown in FIG. 1 , the RAN 103 may include Node-Bs 140a, 140b, 140c, each of which may include one or more transceivers for communicating with the WTRUs 102a, 102b, and 102c over the air interface 115. The Node-Bs 140a, 140b, 140c may be associated with a particular cell (not shown) within the RAN 103. The RAN 103 may also include RNCs 142a, 142b. It will be appreciated that the RAN 103 may include any number of Node-Bs and RNCs while still being consistent with an embodiment.

[0391] like Fig.52CAs shown in FIG. 1 , Node-B 140a, 140b can communicate with RNC 142a. In addition, Node-B 140c can communicate with RNC 142b. Node-B 140a, 140b, 140c can communicate with corresponding RNC 142a, 142b via Iub interface. RNC 142a, 142b can communicate with each other via Iur interface. Each RNC 142a, 142b can be configured to control the corresponding Node-B 140a, 140b, 140c to which it is connected. In addition, each RNC 142a, 142b can be configured to perform or support other functions, such as outer loop power control, load control, admission control, packet scheduling, handover control, macro diversity, security functions, data encryption, etc.

[0392] Fig.52C The core network 106 shown in FIG. 1 may include a media gateway (MGW) 144, a mobile switching center (MSC) 146, a serving GPRS support node (SGSN) 148, and / or a gateway GPRS support node (GGSN) 150. Although each of the above elements are described as being part of the core network 106, it is appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0393] The RNC 142a in the RAN 103 may be connected to the MSC 146 in the core network 106 via an IuCS interface. The MSC 146 may be connected to the MGW 144. The MSC 146 and the MGW 144 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-line communications devices.

[0394] The RNC 142a in the RAN 103 may also be connected to the SGSN 148 in the core network 106 via an IuPS interface. The SGSN 148 may be connected to the GGSN 150. The SGSN 148 and the GGSN 150 may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0395] As described above, core network 106 may also be connected to networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0396] Fig.52D1 is a system diagram of the RAN 104 and the core network 107 according to an embodiment. As described above, the RAN 104 may employ E-UTRA radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 116. The RAN 104 may also be in communication with the core network 107.

[0397] The RAN 104 may include eNode-Bs 160a, 160b, 160c, though it will be appreciated that the RAN 104 may include any number of eNode-Bs while remaining consistent with an embodiment. The eNode-Bs 160a, 160b, 160c may each include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 116. In an embodiment, the eNode-Bs 160a, 160b, 160c may implement MIMO technology. Thus, for example, the eNode-B 160a may use multiple antennas to send and receive wireless signals to and from the WTRU 102a.

[0398] Each eNode-B 160a, 160b, and 160c may be associated with a particular cell (not shown) and may be configured to handle radio resource management decisions, handover decisions, scheduling of users in uplink and / or downlink, etc. Fig.52D As shown in FIG. , eNode-Bs 160a, 160b, 160c may communicate with each other via an X2 interface.

[0399] Fig.52D The core network 107 shown in FIG. 1 may include a mobility management gateway (MME) 162, a serving gateway 164, and a packet data network (PDN) gateway 166. Although each of the above elements are described as being part of the core network 107, it is appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0400] The MME 162 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface and may serve as a control node. For example, the MME 162 may be responsible for authenticating users of the WTRUs 102a, 102b, 102c, bearer activation / deactivation, selecting a particular serving gateway during an initial attach of the WTRUs 102a, 102b, 102c, and the like. The MME 162 may also provide a control plane function for switching between the RAN 104 and other RANs (not shown) that employ other wireless technologies, such as GSM or WCDMA.

[0401] The serving gateway 164 may be connected to each of the eNode-Bs 160a, 160b, and 160c in the RAN 104 via an S1 interface. The serving gateway 164 may generally route and forward user data packets to and from the WTRUs 102a, 102b, 102c. The serving gateway 164 may also perform other functions, such as anchoring the user plane during inter-eNode B handovers, triggering paging when downlink data is available for the WTRUs 102a, 102b, 102c, managing and maintaining the context of the WTRUs 102a, 102b, 102c, and the like.

[0402] The serving gateway 164 may also be connected to the PDN gateway 166, which may provide the WTRUs 102a, 102b, 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, 102c and IP-enabled devices.

[0403] The core network 107 may facilitate communications with other networks. For example, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, 102c and traditional land-based communications devices. For example, the core network 107 may include, or may communicate with, an IP gateway (e.g., an IP Multimedia Subsystem (IMS) server) that acts as an interface between the core network 107 and the PSTN 108. In addition, the core network 107 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks owned and / or operated by other service providers.

[0404] Fig.52E 1 is a system diagram of the RAN 105 and the core network 109 according to an embodiment. The RAN 105 may be an access service network (ASN) that employs IEEE 802.16 radio technology to communicate with the WTRUs 102a, 102b, and 102c over the air interface 117. As further described below, the communication links between the different functional entities of the core network 109, the RAN 105, and the WTRUs 102a, 102b, 102c may be defined as reference points.

[0405] like Fig.52EAs shown in the figure, the RAN 105 may include base stations 180a, 180b, 180c and an ASN gateway 182, although it should be appreciated that the RAN 105 may include any number of base stations and ASN gateways while still being consistent with the embodiment. The base stations 180a, 180b, 180c may all be associated with a particular cell in the RAN 105 and may include one or more transceivers for communicating with the WTRUs 102a, 102b, 102c over the air interface 117. In an embodiment, the base stations 180a, 180b, 180c may implement MIMO technology. Thus, for example, the base station 180a may use multiple antennas to send wireless signals to the WTRU 102a and receive wireless signals from the WTRU 102a. The base stations 180a, 180b, 180c may also provide mobility management functions, such as handover triggering, tunnel establishment, radio resource management, service classification, quality of service (QoS) policy enforcement, etc. The ASN gateway 182 may act as a traffic aggregation point and may be responsible for paging, caching of subscriber profiles, routing to the core network 109, and the like.

[0406] The air interface 117 between the WTRUs 102a, 102b, 102c and the RAN 105 may be defined as an R1 reference point that implements the IEEE 802.16 specification. In addition, each of the WTRUs 102a, 102b, and 102c may establish a logical interface (not shown) with the core network 109. The logical interface between the WTRUs 102a, 102b, 102c and the core network 109 may be defined as an R2 reference point, which may be used for authentication, authorization, IP host configuration management, and / or mobility management.

[0407] The communication link between each of the base stations 180a, 180b, and 180c may be defined as an R8 reference point, which includes protocols that facilitate WTRU handovers and the transfer of data between base stations. The communication link between the base stations 180a, 180b, 180c and the ASN gateway 182 may be defined as an R6 reference point. The R6 reference point may include protocols that facilitate mobility management based on mobility events associated with each of the WTRUs 102a, 102b, 102c.

[0408] like Fig.52E As shown in , the RAN 105 may be connected to a core network 109. The communication link between the RAN 105 and the core network 109 may be defined as an R3 reference point, which includes, for example, protocols that facilitate data transfer and mobility management capabilities. The core network 109 may include a mobile IP home agent (MIP-HA) 184, an authentication, authorization, accounting (AAA) server 186, and a gateway 188. Although each of the above elements are described as part of the core network 109, it is appreciated that any of these elements may be owned and / or operated by an entity other than the core network operator.

[0409] The MIP-HA may be responsible for IP address management and may enable the WTRUs 102a, 102b, and 102c to roam between different ASNs and / or different core networks. The MIP-HA 184 may provide the WTRUs 102a, 102b, and 102c with access to packet-switched networks, such as the Internet 110, to facilitate communications between the WTRUs 102a, 102b, and 102c and IP-enabled devices. The AAA server 186 may be responsible for user authentication and supporting user services. The gateway 188 may facilitate interworking with other networks. For example, the gateway 188 may provide the WTRUs 102a, 102b, and 102c with access to circuit-switched networks, such as the PSTN 108, to facilitate communications between the WTRUs 102a, 102b, and 102c and traditional land-line communication devices. In addition, the gateway 188 may provide the WTRUs 102a, 102b, 102c with access to the networks 112, which may include other wired or wireless networks that are owned and / or operated by other service providers.

[0410] Although not in Fig.52E 105 may be connected to other ASNs and the core network 109 may be connected to other core networks. The communication link between the RAN 105 and the other ASNs may be defined as an R4 reference point, which may include protocols for coordinating the mobility of the WTRUs 102a, 102b, 102c between the RAN 105 and the other ASNs. The communication link between the core network 109 and the other core networks may be defined as an R5 reference point, which may include protocols for facilitating interworking between a home core network and a visited core network.

[0411] Here it is described and Fig.52A , 52C The core network entities illustrated in 52D and 52E are identified using names given to those entities in certain existing 3GPP specifications, although it is understood that these entities and functions may be identified by other names in the future, and that certain entities or functions may be combined in future specifications published by 3GPP, including future 3GPP NR specifications. Fig.52A , 52B The specific network entities and functions described and illustrated in 52C, 52D and 52E are provided as examples only, and it is to be understood that the claimed subject matter disclosed herein may be embodied or implemented in any similar communication system (whether currently defined or defined in the future).

[0412] Fig.52F This can be specifically reflected in Fig.52A , 52C, 52D and 52E of the communication network illustrated in the example of a block diagram of a computing system 90 (such as RAN 103 / 104 / 105, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112 of certain nodes or functional entities). The computing system 90 may include a computer or server, and may be primarily controlled by computer-readable instructions, which may take the form of software, regardless of where such software is stored or accessed, or in any manner. Such computer-readable instructions may be executed in a processor 91 to cause the computing system 90 to work. The processor 91 may be a general-purpose processor, a special-purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors associated with a DSP core, a controller, a microcontroller, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA) circuit, any other type of integrated circuit (IC), a state machine, etc. The processor 91 may perform signal encoding, data processing, power control, input / output processing, and / or any other function that enables the computing system 90 to operate in a communication network. The coprocessor 81 is an optional processor different from the main processor 91 that may perform additional functions or assist the processor 91. The processor 91 and / or the coprocessor 81 may receive, generate, and process data related to the methods and apparatus disclosed herein.

[0413] In operation, processor 91 retrieves, decodes, and executes instructions, and transfers information to and from other resources via the computer system's primary data transfer path, system bus 80. Such a system connects components in computing system 90 and defines the medium for data exchange. System bus 80 generally includes data lines for sending data, address lines for sending addresses, and control lines for sending interrupts and for manipulating the system bus. An example of such a system bus 80 is a PCI (Peripheral Component Interconnect) bus.

[0414] The memory coupled to the system bus 80 includes a random access memory (RAM) 82 and a read-only memory (ROM) 93. Such memory includes circuits that allow information to be saved and retrieved. ROM 93 generally contains saved data that cannot be easily changed. The data saved in RAM 82 can be read or changed by the processor 91 or other hardware devices. Access to RAM 82 and / or ROM 93 can be controlled by a memory controller 92. The memory controller 92 can provide an address translation function that converts a virtual address into a physical address when an instruction is executed. The memory controller 92 can also provide a memory protection function that isolates processes within the system and isolates system processes from user processes. Therefore, a program running in the first mode can only access memory mapped by its own process virtual address space; it cannot access memory in the virtual address space of other processes unless memory sharing between processes is established.

[0415] In addition, computing system 90 may include a peripheral controller 83 responsible for communicating instructions from processor 91 to peripherals such as printer 94 , keyboard 84 , mouse 95 , and disk drive 85 .

[0416] The display 86 controlled by the display controller 96 is used to display the visual output generated by the computing system 90. Such visual output may include text, graphics, animated graphics, and video. The visual output may be provided in the form of a graphical user interface (GUI). The display 86 may be implemented using a CRT-based video display, an LCD-based flat panel display, a gas plasma-based flat panel display, or a touch panel. The display controller 96 includes the electronic components required to generate the video signal sent to the display 86.

[0417] In addition, the computing system 90 may include a network that can be used to connect the computing system 90 to an external communication network (such as Fig.52A , 52B , RAN 103 / 104 / 105 of 52C, 52D and 52E, core network 106 / 107 / 109, PSTN 108, Internet 110 or other network 112) to enable computer 90 to communicate with other nodes or functional entities of these networks, such as communication circuitry, such as network adapter 97. Alone or in combination with processor 91, the communication circuitry can be used to perform the sending and receiving steps of certain devices, nodes or functional entities recorded in this document.

[0418] It is to be understood that any or all of the devices, systems, methods, and processes described herein may be embodied in the form of computer executable instructions (e.g., program code) stored on a computer-readable storage medium, which, when executed by a processor, such as processor 118 or 91, causes the processor to perform and / or implement the systems, methods, and processes described herein. Specifically, any steps, operations, or functions described herein may be implemented in the form of such computer executable instructions running on a processor of a device or computing system configured for wireless and / or wired network communications. Computer-readable storage media include volatile and non-volatile, removable and non-removable media implemented in any non-temporary (e.g., tangible or physical) method or technology for the storage of information, but such computer-readable storage media do not include signals. Computer-readable storage media include (but are not limited to) RAM, ROM, EEPROM, flash memory or other storage technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, cassettes, magnetic tape, disk storage or other magnetic storage devices, or any other tangible or physical media that can be used to store the desired information and can be accessed by a computing system.

[0419] The following is a list of acronyms related to service level technology that may appear in the above descriptions:

[0420] 3GPP Third Generation Partnership Project

[0421] ACK

[0422] AF Application Function

[0423] AN Access Network

[0424] AS Access Layer

[0425] APN Access Point Name

[0426] BCH Broadcast Channel

[0427] BCCH Broadcast Control Channel

[0428] BS Base Station

[0429] BSD bucket size hours

[0430] BSR Buffer Status Report

[0431] CAN connection to the network

[0432] CC Component Carrier

[0433] CCCH Common Control Channel

[0434] CE Control Elements

[0435] CN Core Network

[0436] CP Control Plane

[0437] CPU Central Processing Unit

[0438] CQI Channel Quality Indicator

[0439] C-RNTI Cell Radio Network Temporary Identifier

[0440] CSI Channel State Indicator

[0441] DL Downlink

[0442] DM Device Management

[0443] DN Data Network

[0444] DRB Data Radio Bearer

[0445] eMBB Enhanced Mobile Broadband

[0446] eNB Evolved Node B

[0447] EPC Evolved Packet Core

[0448] E-UTRA Evolved Universal Terrestrial Radio Access

[0449] FEP Stream Encapsulation Protocol

[0450] FPI Flow Priority Indicator

[0451] FPL Flow Priority Level

[0452] GBR Guaranteed Bit Rate

[0453] GW Gateway

[0454] HARQ Hybrid Automatic Repeat Request (HARQ)

[0455] ID Identifier

[0456] IMS IP Multimedia Subsystem

[0457] IMT International Mobile Telecommunications

[0458] IOT or IoT Internet of Things

[0459] IP Internet Protocol

[0460] L2 Data Link Layer

[0461] LCG Logical Channel Group

[0462] LCP Logical Channel Priority

[0463] LTE Long Term Evolution

[0464] MAC Media Access Control

[0465] MCG Master Cell Group

[0466] MCH Multicast Channel

[0467] mIOT Massive Internet of Things

[0468] MTC Machine Type Communication

[0469] mMTC massive machine type communication

[0470] NAS Non-Access Stratum

[0471] NB Narrowband

[0472] NextGen

[0473] NG Next Generation

[0474] NGC Next Generation Core Network

[0475] NR New Radio

[0476] OAM Operation, Maintenance and Management

[0477] OTA

[0478] PBCH Physical Broadcast Channel

[0479] PBR Prioritized Bitrate

[0480] PCH Paging Channel

[0481] PDCP Packet Data Convergence Protocol

[0482] PDSCH Physical Downlink Shared Channel

[0483] PDU Packet Data Unit

[0484] PHY Physical Layer

[0485] PHR Power Headroom Report

[0486] PUCCH Physical Uplink Control Channel

[0487] PUSCH Physical Uplink Shared Channel

[0488] PHY Physical layer (physical layer or sublayer)

[0489] QoS Quality of Service

[0490] RAB Radio Access Bearer

[0491] RACH Radio Access Channel

[0492] RAN Radio Access Network

[0493] RAT Radio Access Technology

[0494] RB Resource Block or Radio Bearer

[0495] RLC Radio Link Control

[0496] RNTI Radio Network Temporary Identifier

[0497] RRC Radio Resource Control

[0498] RQI Reflective QoS Indicator

[0499] Rx Receiver

[0500] SA2 Services and Systems Aspects Working Group 2

[0501] SAP Service Access Point

[0502] SCell Secondary Cell

[0503] SpCell Special Cell

[0504] SCG Secondary Cell Group

[0505] SCH Shared Channel

[0506] SDU Service Data Unit

[0507] SL Secondary Link

[0508] SPID Subscriber Profile ID

[0509] SR Scheduling Request

[0510] SRB Signalling Radio Bearer

[0511] TFF Business Flow Filter

[0512] TFT Business Flow Template

[0513] TRP Send and Receive Points

[0514] TTI Transmit Time Interval

[0515] Tx Transmitter

[0516] UCI Uplink Control Information

[0517] UDP User Datagram Protocol

[0518] UE User Equipment

[0519] UL Uplink

[0520] UP User Plane

[0521] URLLC Ultra-Reliable Low Latency Communications

[0522] UTRAN Universal Terrestrial Radio Access Network

Claims

1. A device, comprising a processor, a memory, and a communication circuit, the device comprising a plurality of logical channels configured to connect to a network through the communication circuit of the device, the device further comprising computer executable instructions stored in the memory of the device, the computer executable instructions, when executed by the processor of the device, causing the device to perform operations comprising: receiving a data radio bearer DRB configuration, wherein the DRB configured by the DRB configuration is mapped to a quality of service QoS flow in a first layer; receiving a resource configuration indicating one or more restrictions for a logical channel for an uplink grant; preparing a first data packet having a header including a first QoS flow identifier ID as a packet tag in a first layer, the first QoS flow ID being set according to a QoS flow mapped to the DRB, wherein the first layer is higher than a PDCP layer; A first data packet is sent via a first logical channel, wherein the first logical channel is selected in the second layer based on the one or more restrictions of logical channels.

2. The device according to claim 1, wherein: The resource configuration includes at least one of a parameter set restriction of a logical channel with respect to a subcarrier spacing SCS, a duplication restriction of a logical channel with respect to one or more component carriers CC, and a lifetime restriction associated with a logical channel of an uplink grant, The replication restriction is used to restrict logical channels associated with one or more DRBs in the DRB from having replication in the PDCP layer.

3. The device of claim 1 , further comprising computer executable instructions stored in a memory of the device, the computer executable instructions, when executed by a processor of the device, causing the device to perform operations comprising: receiving a second data packet having a header including a second QoS flow ID as a packet marking in the first layer; preparing a third data packet having a header including a third QoS flow ID as a packet marking in the first layer, the third QoS flow ID being set according to the second QoS flow ID; as well as The third data packet is sent via a second logical channel, wherein the second logical channel is selected in the second layer based on the one or more restrictions of the logical channels.

4. The device according to claim 1, wherein: The first data packet is sent to a network in uplink communication, or is sent to other devices in inter-device communication.

5. A device comprising a processor, a memory and a communication circuit, the device comprising a plurality of logical channels configured to connect to a network through the communication circuit of the device, the device further comprising computer executable instructions stored in the memory of the device, the computer executable instructions, when executed by the processor of the device, causing the device to perform operations comprising: sending a data radio bearer DRB configuration, wherein the DRB configured by the DRB configuration is mapped to a quality of service QoS flow in a first layer; sending a resource configuration indicating one or more restrictions on a logical channel for an uplink grant; and receiving a first data packet having a header including a first QoS flow identifier ID as a packet tag in a first layer through a first logical channel, the first QoS flow ID being set according to a QoS flow mapped to a DRB, wherein, The first layer is higher than the PDCP layer, and The first logical channel is selected in the second layer based on the one or more restrictions of the logical channel.

6. The device according to claim 5, wherein: The resource configuration includes at least one of a parameter set restriction of a logical channel with respect to a subcarrier spacing SCS, a duplication restriction of a logical channel with respect to one or more component carriers CC, and a lifetime restriction associated with a logical channel of an uplink grant, The replication restriction is used to restrict logical channels associated with one or more DRBs in the DRB from having replication in the PDCP layer.

7. The device of claim 5, further comprising computer executable instructions stored in a memory of the device, the computer executable instructions, when executed by a processor of the device, causing the device to perform operations comprising: sending a second data packet having a header including the second QoS flow ID as a packet marking in the first layer; and receiving, through the second logical channel, a third data packet having a header including a third QoS flow ID as a packet marking in the first layer, the third QoS flow ID being set according to the second QoS flow ID, in, The second logical channel is selected in the second layer based on the one or more restrictions of the logical channels.

8. The apparatus according to claim 5, wherein: The first data packet is sent to a network in uplink communication, or is sent to other devices in inter-device communication.

9. A method for a network system, the method comprising: sending a data radio bearer DRB configuration, wherein the DRB configured by the DRB configuration is mapped to a quality of service QoS flow in a first layer; sending a resource configuration indicating one or more restrictions on a logical channel for an uplink grant; as well as receiving, through a first logical channel, a first data packet having a header including a first QoS flow identifier ID as a packet tag in a first layer, the first QoS flow ID being set according to a QoS flow mapped to a DRB, wherein the first layer is higher than a PDCP layer, and The first logical channel is selected in the second layer based on the one or more restrictions of the logical channel.

10. The method according to claim 9, wherein: The resource configuration includes at least one of a parameter set restriction of a logical channel with respect to a subcarrier spacing SCS, a duplication restriction of a logical channel with respect to one or more component carriers CC, and a lifetime restriction associated with a logical channel of an uplink grant, The replication restriction is used to restrict logical channels associated with one or more DRBs in the DRB from having replication in the PDCP layer.

11. The method according to claim 9, further comprising: sending a second data packet having a header including a second QoS flow ID as a packet marking in the first layer; as well as receiving, through the second logical channel, a third data packet having a header including a third QoS flow ID as a packet marking in the first layer, the third QoS flow ID being set according to the second QoS flow ID, The second logical channel is selected in the second layer based on the one or more restrictions of the logical channel.

12. The method according to claim 9, wherein: The first data packet is sent to a network in uplink communication, or is sent to other devices in inter-device communication.

Images