Mini token bucket for uplink transmission
By using a mini token bucket scheme in 5G uplink transmission, the priority of QoS flows is mapped to the group token level, which solves the problem of inflexible resource allocation in the existing technology and realizes differentiated service and efficient transmission for different QoS flows.
Patent Information
- Application Number
- CN202180017809.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2020-03-02
- Filing Date
- 2021-01-08
- Publication Date
- 2026-03-06
- Estimated Expiration
- 2041-01-08
AI Technical Summary
Existing 5G wireless communication systems lack an effective mechanism to differentiate and prioritize resource allocation for different quality of service streams in uplink transmission, resulting in inflexible resource allocation and an inability to meet the different QoS requirements of various services.
The mini token bucket scheme flexibly maps the priority of the quality of service flow to the group token level. By dequeuing grouped data in priority order through the mini token bucket byte resources, the constant data rate transmission of high-priority flows is ensured.
It enables differentiated services for different QoS streams in 5G uplink transmission, improves the flexibility and efficiency of resource allocation, ensures priority processing of latency-sensitive applications, and reduces the latency of low-priority data.
Smart Images

Figure CN115211197B_ABST
Abstract
Description
[0001] Cross-references to related applications
[0002] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 984180, filed March 2, 2020, the entire contents of which are incorporated herein by reference. Background Technology
[0003] Embodiments of this disclosure relate to the field of communications, and can be used for preparing data for uplink transmission.
[0004] Wireless communication systems are widely deployed to provide a variety of telecommunications services, such as telephone, video, data, messaging, and broadcasting. Various wireless communication systems rely on uplink communication for data. For example, in fifth-generation (5G) communication systems, access nodes can schedule uplink transmissions for one or more user equipment (UE) devices. The UE device can be responsible for transmitting data in the uplink according to the schedule. When a UE sends data, it may have to send more data than it can send within the schedule. Accordingly, the UE may need to send data according to some priority order. Summary of the Invention
[0005] Embodiments of methods and apparatus for preparing data to be transmitted in uplink communications are disclosed herein.
[0006] In one example, a method for packet preparation for uplink transmission may include: determining a Quality of Service (QoS) identifier associated with the QoS flow by a user equipment (UE). The method further includes: mapping the QoS identifier to a group token level by the UE. The method also includes: processing the QoS flow based on the group token level by the UE.
[0007] In another example, the means for packet preparation for uplink transmission may include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured, using the at least one processor, to cause the means to at least determine a Quality of Service (QoS) identifier associated with the QoS flow. The at least one memory and the computer program code may also be configured, using the at least one processor, to cause the means to at least map the QoS identifier to a group token level. The at least one memory and the computer program code may also be configured, using the at least one processor, to cause the means to process the QoS flow at least according to the group token level.
[0008] In another example, the non-transitory computer-readable medium may be encoded with instructions that, when executed by a processor, cause the processor to perform at least the processing for packet preparation for uplink transmission. This processing may include: determining a Quality of Service (QoS) identifier associated with the QoS flow by the user equipment. The processing may also include: mapping the QoS identifier to a group token level by the user equipment. The processing may further include: processing the QoS flow by the user equipment based on the group token level.
[0009] In another example, the baseband chip for packet preparation for uplink transmission may include a service data adaptation protocol circuit, a packet data aggregation protocol circuit, and a media access control circuit. The service data adaptation protocol circuit can be configured to determine a quality of service identifier associated with the quality of service flow, map the quality of service identifier to a group token level, process the quality of service flow according to the group token level, and provide the quality of service flow to the packet data aggregation protocol circuit for transmission to the media access control circuit for transmission by the physical layer circuitry. Attached Figure Description
[0010] The accompanying drawings, which are included in and form part of this specification, illustrate embodiments of the present disclosure and are further used in conjunction with the specification to explain the principles of the present disclosure, so as to enable those skilled in the art to make and use the present disclosure.
[0011] Figure 1 A schematic diagram of the modem data processing stack is shown;
[0012] Figure 2 An example method for packet preparation for uplink transmission according to certain embodiments of the present disclosure is shown;
[0013] Figure 3 An overflow of a packet stream according to certain embodiments of this disclosure is shown;
[0014] Figure 4 Examples of group token level usage corresponding to Table 1 according to certain embodiments of this disclosure are shown;
[0015] Figure 5 An example wireless network according to certain embodiments of this disclosure is shown;
[0016] Figure 6 A block diagram of an example node according to certain embodiments of the present disclosure is shown;
[0017] Figure 7 A block diagram of an apparatus according to some embodiments of the present disclosure is shown;
[0018] Figure 8 Detailed block diagrams of example baseband chips according to some embodiments of the present disclosure are shown.
[0019] The embodiments disclosed herein will be described with reference to the accompanying drawings. Detailed Implementation
[0020] Although specific configurations and arrangements have been discussed, it should be understood that this is for illustrative purposes only. Those skilled in the art will appreciate that other configurations and arrangements may be used without departing from the spirit and scope of this disclosure. It will be apparent to those skilled in the art that this disclosure can also be used in a variety of other applications.
[0021] It should be noted that references to "an embodiment," "an embodiment," "an exemplary embodiment," "some embodiments," "certain embodiments," etc., in the specification indicate that the described embodiments may include specific features, structures, or characteristics, but each embodiment may not necessarily include the specific features, structures, or characteristics. Furthermore, such phrases do not necessarily correspond to the same embodiment. Moreover, when a specific feature, structure, or characteristic is described in conjunction with an embodiment, the feature, structure, or characteristic can be implemented by combining it with other embodiments, whether explicitly described or not, within the knowledge of those skilled in the art.
[0022] Generally speaking, terms can be understood, at least in part, based on their use in context. For example, the term "one or more," as used herein, depends at least in part on the context and may be used to describe any feature, structure, or characteristic in a singular sense, or to describe a combination of features, structures, or characteristics in a plural sense. Similarly, terms such as "a," "one," or "the" can be understood to express either a singular or a plural usage, depending at least in part on the context. Furthermore, the word "based on" can be understood to not necessarily be intended to express a single set of factors; rather, it may allow for the presence of additional factors that are not necessarily explicitly described, which also depends at least in part on the context.
[0023] The techniques described in this article can be used in various wireless communication networks, such as Long-Term Evolution (LTE) systems, code division multiple access (CDMA) systems, time division multiple access (TDMA) systems, frequency division multiple access (FDMA) systems, orthogonal frequency division multiple access (OFDMA) systems, single-carrier frequency division multiple access (SC-FDMA) systems, and others. The terms "network" and "system" are often used interchangeably. CDMA networks can implement wireless technologies such as Universal Terrestrial Radio Access (UTRA) and CDMA 2000. UTRA includes Wideband CDMA (WCDMA) and other variants of CDMA. CDMA 2000 encompasses the IS-2000, IS-95, and IS-856 standards. TDMA networks can implement wireless technologies such as the Global System for Mobile Communications (GSM). OFDMA networks can implement wireless technologies such as New Radio (NR) (e.g., 5G RAT), Evolved UTRA (E-UTRA), Ultra Mobile Broadband (UMB), IEEE 802.11 (Wi-Fi), IEEE 802.16 (WiMAX), IEEE 802.20, and Flash-OFDMA. UTRA and E-UTRA are part of the Universal Mobile Telecommunication System (UMTS). NR is an emerging wireless communication technology developed in conjunction with the 5G Technology Forum (5GTF). 3GPP Long Term Evolution (LTE) and LTE-Advanced (LTE-A) are new releases of UMTS using E-UTRA.UTRA, E-UTRA, UMTS, LTE, LTE-A, and GSM are described in documents from an organization called the 3rd Generation Partnership Project (3GPP). CDMA2000 and UMB are described in documents from an organization called the 3rd Generation Partnership Project 2 (3GPP2). The technologies described herein can be used in the aforementioned wireless networks and wireless technologies, as well as other wireless networks and wireless technologies.
[0024] Figure 1 The modem data processing stack is shown. (Example) Figure 1 As shown, in a 5G cellular modem, the packet data protocol stack includes the Internet Protocol (IP) layer (also known as Layer 3, L3), the Packet Data Convergence Protocol (PDCP) layer, the Radio Link Control (RLC) layer, and the Media Access Control (MAC) layer. Each layer is responsible for processing user plane packet data in the form of IP data or raw user data, and ensuring that data transmission is secure, timely, and error-free. User equipment (UE) can be configured to transmit uplink data packets through resource allocation scheduled by the network, such as through base stations.
[0025] In the uplink (UL) direction, packet data from external application processors (APs) and hosts (e.g., via universal serial bus (USB) or PCIe (peripheral component interconnected express)) arrives at the L3 protocol stack in the form of IP packets within Protocol Data Unit (PDU) sessions. These IP packets are classified into L3 Quality of Service (QoS) flows and mapped to each data radio bearer (DRB), as shown in DRB1, DRB2, and DRB3. Therefore, IP packets input by the AP / host can initially be classified as L3 QoS flows with QoS flow indicators (QFIs) and can be mapped to specific data radio bearers based on network requirements for packets with similar service needs.
[0026] Packets in each DRB are dequeued and processed by the PDCP layer. PDCP layer processing includes robust header compression (ROHC) and security features such as integrity checks and encryption. Once PDCP layer processing is complete, packets are queued to their corresponding Layer 2 (L2) logical channels, designated LC0, LC1, LC2, LC3, LC4, LC5, and LC6. Simultaneously, modem signaling messages also arrive at their designated L2 logical channels.
[0027] At the physical (PHY) layer, in each timeslot, the physical downlink control channel (PDCCH) containing downlink control indicator (DCI) information is decoded. The DCI contains dynamic grant allocation for dynamic uplink transmissions transmitted at the indicated timeslot.
[0028] At the MAC layer, once the size of the dynamic grant allocation is calculated, the modem can dequeue from the logical channel and collect L2 packets using the logical channel prioritization (LCP) algorithm specified in the 3GPP standard. Typically, grant bytes are evenly distributed across all L3 QoS flows, regardless of priority. When a grant byte becomes available on the logical channel, it is dequeued according to a first-come-first-served scheme. The MAC layer can then combine MAC Protocol Data Units (PDUs) into a transport block for transmission at the PHY layer. Each component carrier has one such transport block. Therefore, packet data is transmitted from the packet stack to the base station according to the uplink grant size allocated by the base station (BS) for each time slot based on the logical channel prioritization.
[0029] Therefore, in each time slot, the network can allocate a grant size for uplink transmission to the user equipment. The UL MAC at the UE can then perform LCP to schedule the allocation grant for each logical channel. Based on these grant bytes for each LC, a maximum number of data packets within the grant allocation can be dequeued by the MAC, where these data packets can be combined into a MAC PDU for UL data transmission.
[0030] After L3 data arrives at the modem, MAC sub-PDU (MacSubPDU) packets can be prepared in the L2 logical channel queue. Once the dynamic grant is allocated by the base station and received by the MAC layer, the MAC layer can perform logical channel prioritization to create a MAC PDU with a specific grant size. Accordingly, packets in the logical channel are extracted from the logical channel priority list according to priority. The MAC PDU is then transmitted to the physical layer for transmission.
[0031] In another path, logical channel L2 data in each individual logical channel queue is combined into a contiguous block in several packets at a time. However, because the exact grant allocation size is not yet known, they are not prepared in MAC PDU format. Once the dynamic grant is allocated by the base station and received by the MAC layer, the MAC layer performs logical channel prioritization to create a MAC PDU with an exact grant size. Accordingly, packets in the logical channel are extracted according to priority based on the logical channel prioritization. The MAC PDU is then transmitted to the physical layer for transmission. The assembly of the first transport block corresponding to component carrier (CC)1 is shown for component carrier (CC), and similar assembly can certainly occur for each of CC2 and CC3, etc. Each component carrier may include one transport block.
[0032] Typically, the physical layer can store a copy of the entire transport block at the PHY layer for retransmission purposes.
[0033] One challenge in UL MAC transmission is the service of grant bytes per logical channel for transmitting MAC PDU content. Given a calculated grant size allocated to a logical channel, UL MAC may need to dequeue packets from the L2 logical channel queue, which may be fed by multiple L3 QoS streams. Emptying these data packets from the L3 QoS streams into the L2 LC can pose challenges to its various QoS stream parameters and is not defined by existing standards.
[0034] As a result, differentiated services may be lacking for all QoS flows within each logical channel. Furthermore, regardless of the application's QoS requirements, there may be situations where resources are allocated inefficiently with only one priority level. Moreover, inflexible resource allocation may exist for services with only one type of service and latency requirement.
[0035] Certain embodiments of this disclosure provide a 5G UL scheduling method for prioritizing packet data from L3 QoS outflows to L2 logical channels for UL MAC PDU data transmission. These embodiments take into account key QoS parameters and can provide a simple, fast, and efficient mechanism to allocate licensed bytes to each flow to be used without waste, thereby enabling differentiated service processing for each QoS flow.
[0036] Some embodiments of this disclosure may use any of the following three aspects individually or in combination: a priority scheme for dequeuing L3 packets in each UL QoS flow sharing the same DRB, flexibly mapping the priority of each QoS flow to a group token level for resource allocation, or access scheduling packet transmission for each QoS flow according to its group token level.
[0037] For example, in some embodiments, scheduling L3 data packets from several UL QoS flows sharing the same DRB to an L2 MAC for UL transmission can be differentiated for each flow with optimized performance. For a given LC token bucket byte resource from the L2 MACLCP for each LC, that resource can be optimally allocated to each UL QoS flow constituting the DRB channel.
[0038] In another example, some implementations consider the 5G QoS characteristics of QoS flows, including priority levels, resource service types, and packet delay budgets or delay requirements, and can map them to “group token levels” with defined resource allocation bytes. Mappings can be defined whenever a QoS flow is set up, and can be flexibly adjusted at static setup or dynamic runtime to meet the performance requirements of the application.
[0039] In another example, in some embodiments, a given total LC token bucket byte resource from the L2 LCP for each LC can be allocated to each QoS flow based on the group token access level of each QoS flow. Packets can be pulled into an L2 MAC PDU for transmission at the next transport slot / symbol.
[0040] Figure 2 An example method 200 for packet preparation for uplink transmission according to certain embodiments of this disclosure is shown. Figure 2 As shown, method 200 may include: at 210, when radio resource control is established, mapping each QoS flow to a group token level for each LC.
[0041] When setting up, for each LC, the mapping of each QoS flow to the group token level can be performed in various ways; the following description provides an example.
[0042] At QoS flows configured using QFI, the system can construct a mapping from each flow's 5QI attributes (e.g., priority level, service resource type, and / or packet delay budget) to the group token level using the associated 5QI identifier (5QI). Depending on application requirements, this mapping can be flexibly adjusted for each DRB using weighted values K1, K2, and K3, and can be set individually for each LC or even each QoS flow.
[0043] Therefore, the group token level (L) = (K1)*(P) + (K2)*(R) + (K3)*(D), where L is the group token level of the QoS flow identifier queue, P is the mapping priority level of the QoS flow (ranging from 1 to 100), R is the mapping resource type (non-GBR, GBR, or Delay-Critical GBR), and D is the mapping packet delay budget (ranging from 5ms to 500ms). Separate Group_Token_Levels can be any implementation of a specific level.
[0044] Table 1 shows examples of possible mappings:
[0045]
[0046] Table 1
[0047] Figure 2 This demonstrates how this mapping can be statically determined during setup to configure the group token level. This allows for adjustments to be made for each flow or DRB as needed.
[0048] Figure 4 An example of group token level usage corresponding to Table 1 according to certain embodiments of this disclosure is shown. In this example, QoS flows are mapped to eight group token levels, where level 8 is the highest priority and level 1 is the lowest priority. Priority levels can be mapped from 1 to 100 to these eight levels as shown in Table 1, or in any other desired manner. Similarly, resource types can be mapped such that the guaranteed bit rate (GBR) is mapped to level 8, GBR to level 6, and non-GBR to level 3, although any other desired mapping may also be used. Likewise, packet delay budgets can be mapped across the eight levels such that 5–20 ms is mapped to level 8, 401–500 ms to level 1, and other intervals to levels 2–7 (see Table 1 for more details of this example), although any other desired mapping may also be used.
[0049] Using weighting coefficients K1, K2, and K3, the normalized group token level (L) can be obtained. L reflects the expected priority token level of the flow corresponding to a given QoS flow identifier.
[0050] Some implementations can assign an infinite priority queue with the highest priority and no bucket size limit to the absolutely highest priority application, such as a Transmission Control Protocol (TCP) acknowledgment (ack) for logical channel TCP / IP transmissions.
[0051] exist Figure 4 In the example, QFI A has been determined to have a group token level of 8, QFI B has been determined to have a group token level of 8, QFI C has been determined to have a group token level of 4, QFID has been determined to have a group token level of 2, and QFI E has been determined to have a group token level of 1.
[0052] like Figure 2 As shown, in step 215, the system implementing this method (e.g., a user equipment, modem, or other component or subcomponent thereof) can, for each LC, sort the QoS flows according to priority access order using group token levels. Therefore, once the mapping is complete, the QoS flow L3 queues can be sorted according to priority access order, with the highest group token level placed at the head of the queue. Figure 4 In the example, the stream of QFI A has the highest level, as does the stream of QFI B. When streams are at the same level (tie), the system can randomly select between streams of the same level.
[0053] like Figure 2 As shown, at 220, for each time slot, the system can use NW grants to run LCP to obtain an LC token bucket size grant for each LC. Once the UE is in connected mode, in each time slot, the network can allocate the number of bytes of the grant size for each component carrier and each MAC instance corresponding to the transport block. Then, according to the 3GPP MAC standard, this grant can be allocated to the UE's logical channels according to the LCP algorithm, where each logical channel j is given a grant allocation up to bucket level Bj. Through this grant allocation, each logical channel can dequeue packet data to the MAC, and the MAC can assemble MACPDUs and schedule data transmission for each time slot.
[0054] In the mini-token bucket scheme, the total LC token bucket bytes of resources from the L2 LCP for each LC can be further allocated to each QoS flow based on the group token level access of each QoS flow, so as to dequeue groups according to QoS priority levels.
[0055] For example, such as Figure 2 As shown, at 225, for each LC, the system can run a mini-token bucket scheme to allocate LC token bytes to each flow. The mini-token bucket scheme can include: at 230, calculating the bytes for each group of token levels for a given LC; at 235, calculating the number of mini-token bucket bytes for each flow; at 240, dequeuing up to the number calculated at 235 plus any donated tokens; at 245, determining if any tokens remain; at 250, giving any remaining tokens to the next flow; and at 255, determining if all flows have been served for a given LC.
[0056] If it is determined at 245 that no tokens remain, the grant at 250 can be ignored. If it is determined at 255 that no streams are served, the system can calculate the mini-token bucket bytes for the next stream at 235. Optionally, the mini-token bucket bytes for all streams of a given LC can be calculated first, and then adjusted based on any granted tokens.
[0057] When it is determined that all flows have been served for a given LC, the system can determine at 260 whether all LCs have been served. If not, the system can repeat the mini-token bucket scheme starting at 225 for the next LC. Otherwise, at 265, the system can use the dequeued data to assemble a MAC PDU and provide the MAC PDU to the physical layer for transmission. At 270, the system can then wait for the next time slot, which can trigger the process to continue from 220.
[0058] The calculation at 230 can be performed in various ways. For example, BBj can be the total LC token bucket byte resource calculated according to L2LCP for a given LCj. In this case, BBj = Min[Bj, GrantLeft], where Bj is the bucket level obtained from the L2 MAC for that LCj at the current transport slot / time according to the LCP algorithm (see, for example, 3GPP2 TS38.321), and GrantLeft is the remaining MAC grant size for that LCj after servicing any higher priority LC, and where the MAC grant size is the resource allocation given by NW to the UE for that MAC instance. B_n, the bytes for each group token level at slot n, can be calculated as: B_n = BBj / (∑(Group_Token_Levels) for all flows). This sum can be the sum of all token levels for each flow, and B_n can be the base token byte for each level unit for that DRB / LCj at the current slot n.
[0059] Similarly, the computation at 235 can be performed in various ways. For example, for each stream i in this DRB / LCj, MB_i, the stream mini-token bucket byte, can be derived. This can be the token resource allocation byte for stream i. For example, MB_i = (L_i).(B_n), where MB_i is the stream mini-token bucket byte for stream i at slot n, L_i is the group token level for stream i, and B_n is the byte for each group token level at slot n.
[0060] Figure 4 An example of dequeuing at position 240 is shown. For each stream i, data groups can be dequeued until the token bytes (MB_i) for that stream are used up. If the stream mini-token bucket bytes from a priority stream are unused after all data in stream queue i has been dequeued, the unused bytes can go to the next priority stream in the route. This can be done... Figure 4 It can be seen that QFI A contains unused stream mini token bucket bytes, which are then sent to QFI B, and then a small number of unused stream mini token bucket bytes in QFI B are sent to QFI C.
[0061] All stream token bucket bytes can be reset for each transmission slot. This ensures that high-priority streams have a constant, guaranteed data rate transmission. Token bytes from the highest-priority stream are only given to the next lower-priority stream when the stream has exhausted its data.
[0062] As mentioned above, and as Figure 2As shown, the process can be performed until all QoS streams for a given LC j have been served, where either all BBj (total LC token bucket bytes for that LC j) have been used up, or all data bytes from all QoS streams have been completely dequeued.
[0063] Once all QoS flows in an L3 QoS flow have been served, the remaining licenses can be allocated to the next L3 QoS flow to be served, until all L3 QoS flows have been served. Then, a MAC PDU can be assembled from packets dequeued from the L3 QoS flows and sent to the PHY layer for transmission.
[0064] Therefore, by using the methods in some embodiments of this disclosure, data from multiple L3 QoS flows in the same DRB / LC can be dequeued quickly with optimal priority performance using minimal complexity.
[0065] Figure 3 This illustrates an overflow of a packet stream according to certain embodiments of this disclosure. For example... Figure 3 As shown, data can be retrieved from the IP stream from top to bottom, placed into the L3 QoS stream queue, and then into the L2 logical channel queue. The L2 logical channels can be prioritized according to their priority, and the data can be formatted into MACPDUs corresponding to transport block grants.
[0066] More specifically, such as Figure 3 As shown, QoS rules can be used to map IP flows to QoS flows. For each data radio bearer, this allows multiple different QoS flows to have their own QFI. The use of mini token bucket schemes, for example, is illustrated above. Figure 2 The described method can be used to schedule L3 QoS flow packets to allocate licenses to each LC.
[0067] Next, PDCP processing can be performed, as shown above. Figure 1 The described path leads to L2 logical channel queues. Logical channel priority allocation can be performed on these L2 logical channel queues, generating MAC sub-PDUs that can be assembled with MAC control elements (CEs), etc., to form a MAC PDU in each MAC instance.
[0068] Certain embodiments of this disclosure may offer various benefits and / or advantages. For example, some embodiments may provide a simple and practical solution with minimal software complexity. Furthermore, some embodiments may provide enhanced performance through priority grouping and delivery for latency-sensitive applications. Additionally, some embodiments may provide differentiated services for applications with different QoS flow requirements. Furthermore, some embodiments may eliminate the lack of data transmission for low-priority applications. Moreover, some embodiments may provide efficient service allocation to all application service flows with maximum license utilization and minimal waste.
[0069] Figure 5 An example wireless network 500, such as an NR or 5G network, is illustrated, in which various aspects of this disclosure can be performed, such as implementing uplink data preparation, as described in more detail below. Figure 5 As shown, wireless network 500 may include a network of nodes (e.g., user equipment 510, access node 520, and core network element 530). User equipment 510 may be any terminal device, such as a smartphone, personal computer, laptop, tablet computer, vehicle computer, wearable electronic device, smart sensor, or any other device capable of receiving, processing, and transmitting information, such as any component of a vehicle-to-everything (V2X) network, trunked network, smart grid node, or Internet of Things (IoT) node. Other devices are also permitted. User equipment 510 is illustrated as a smartphone only by way of example and not by way of limitation.
[0070] Access node 520 can be a device that communicates with user equipment 510, such as a wireless access point, base station, enhanced Node B (eNB), or trunking master node. Access node 520 can be wired to user equipment 510, wirelessly connected to user equipment 510, or any combination thereof. Access node 520 can connect to user equipment 510 through multiple connection points, and user equipment 510 can connect to other access nodes besides access node 520. Access node 520 can also connect to other user equipment. Access node 520 is illustrated as a radio tower by way of example, not by way of limitation.
[0071] Core network element 530 can serve access node 520 and user equipment 510 to provide core network services. Examples of core network elements 530 include home subscriber server (HSS), mobility management entity (MME), serving gateway (GW), and packet data network (PDN) GW. These are examples of core network elements in an evolved packet core (EPC) system, which is the core network of an LTE system. Other core network elements can be used in LTE and other communication systems. Core network element 530 is shown by way of example, and not by way of limitation, as a collection of servers mounted on a rack.
[0072] Core network element 530 can be connected to a large network such as the Internet 540 or another IP network to transmit packet data over any distance. In this way, data from user equipment 510 can be transmitted to other user equipment connected to other access points, including, for example, a personal computer 550 connected to the Internet 540 via a wired connection, or a tablet 570 connected to the Internet 540 via a router 560. Thus, the personal computer 550 and tablet 570 provide additional examples of possible user equipment devices, while the router 560 provides an example of another access point device.
[0073] A general example of a rack-mounted server is provided as an example of core network element 530. However, multiple elements may exist in the core network, including database servers, such as database 580, and security and authentication servers, such as authentication server 590. For example, database 580 may manage data related to user subscriptions to network services. A home location register (HLR) is an example of a standardized database used for subscription information for mobile networks. Similarly, authentication server 590 may handle authentication of users, sessions, etc. In 5G, the authentication server function (AUSF) may be a specific entity that performs user equipment authentication. In some embodiments, a single server rack may handle multiple such functions, such that the connection between core network element 530, authentication server 590, and database 580 may be a local connection within a single rack.
[0074] Some embodiments of this disclosure can be implemented in a modem of a user equipment (e.g., user equipment 510, tablet 570, or personal computer 550). For example, the modem or other transceiver of user equipment 510 can prepare packets for communication transmission and retransmission from access node 520. As described in detail above, user equipment 510 can prepare packets and appropriately store them at the MAC layer.
[0075] Figure 5 Each element in the above can be considered a node in a communication network. The following... Figure 6 The Node 600 description provides further details, with examples, about possible implementations of the communication node. For instance, Figure 5 User equipment 510 in the middle can be implemented as Figure 6 Node 600 is shown in the diagram.
[0076] Figure 6 Devices according to certain embodiments of this disclosure are shown. Figure 6 As shown, node 600 can include various components. Node 600 can correspond to... Figure 5 User equipment 510, access node 520, or core network element 530 are included. In some embodiments, node 600 corresponds to... Figure 5 The modem in user equipment 510, access node 520 or core network element 530.
[0077] like Figure 6 As shown, node 600 may include processor 610, memory 620, and transceiver 630. These components are shown interconnected via a bus, but other connection types are also permitted. Transceiver 630 may include any suitable device for sending and / or receiving data. Node 600 may include one or more transceivers, although only one transceiver 630 is shown for the sake of simplicity. Antenna 640 is shown as a possible communication mechanism for node 600. Multiple antennas and / or antenna arrays may be utilized. Alternatively, examples of node 600 may communicate using wired technologies instead of (or wireless technologies other than wireless technologies). For example, access node 520 may communicate wirelessly with user equipment 510 and may communicate with core network element 530 via a wired connection (e.g., via fiber optic or coaxial cable). Other communication hardware, such as network interface card (NIC), may be included.
[0078] When node 600 is a user device, it may also include additional components such as a user interface (UI), sensors, etc. Similarly, when node 600 is configured as a core network element 530, node 600 can be implemented as a blade in a server system. Other implementations are also possible.
[0079] like Figure 6 As shown, node 600 may include processor 610. Although only one processor is shown, it should be understood that multiple processors may be included. Processor 610 may be any suitable computing device, such as a central processing unit (CPU), microcontroller unit (MCU), application-specific integrated circuit (ASIC), field-programmable gate array (FPGA), etc. Processor 610 may be a hardware device having one or more processing cores. In some embodiments where node 600 corresponds to a modem, processor 610 may be a baseband processor.
[0080] like Figure 6 As shown, node 600 may also include memory 620. Although only memory is shown, it should be understood that multiple memories may be included. Memory 620 may broadly include both main memory and external storage devices. For example, memory 620 may include random access memory (RAM) included on the same chip as processor 610. Memory 620 may also include external storage devices such as hard disk drives (HDDs), solid-state drives (SSDs), etc. Other memory types and external storage device types are also permitted.
[0081] Similarly, node 600 can also be configured as Figure 5 The node 600 may be a personal computer 550, router 560, tablet 570, database 580, or authentication server 590. The node 600 can be configured to perform any of the above methods using hardware alone or hardware and software together.
[0082] Another aspect of the invention relates to a non-transitory computer-readable medium encoded with instructions, which are read by at least one processor (e.g., Figure 6When executed by the processor 610, any of the processing methods disclosed herein are performed. The computer-readable medium may include volatile or non-volatile, magnetic, semiconductor, magnetic tape, optical, removable, non-removable, or other types of computer-readable media or computer-readable storage devices. For example, as disclosed, the computer-readable medium may be an external storage device or internal storage module on which computer instructions are stored. In some embodiments, the computer-readable medium may be a disk, flash drive, or solid-state drive on which computer instructions are stored.
[0083] Figure 7 A block diagram of an apparatus 700 including a baseband chip 702, an RF chip 704, and a host chip 706 according to certain embodiments of the present disclosure is shown. The apparatus 700 may be... Figure 5 Examples of any suitable nodes in the wireless network 500, such as user equipment 510 or access node 520. Figure 7 As shown, device 700 may include a baseband chip 702, an RF chip 704, a host chip 706, and one or more antennas 710. In some embodiments, the baseband chip 702 is implemented by a processor 610 and a memory 620, and the RF chip 704 is implemented by a processor 610, a memory 620, and a transceiver 630, as described above regarding... Figure 6 As described above. In addition to the on-chip memory (also known as "internal memory" or "local memory," such as registers, buffers, or caches) in each chip 702, 704, or 706, device 700 may also include external memory 708 (e.g., system memory or main memory), which can be shared by each chip 702, 704, or 706 via a system / main bus. Although the baseband chip 702 is... Figure 7 The following are shown as independent SoCs. It is understood that in one example, the baseband chip 702 and the RF chip 704 can be integrated into a SoC; in another example, the baseband chip 702 and the host chip 706 can be integrated into a SoC; and in yet another example, as described above, the baseband chip 702, the RF chip 704, and the host chip 706 can be integrated into a SoC.
[0084] In the uplink, host chip 706 can generate raw data and send it to baseband chip 702 for encoding, modulation, and mapping. Baseband chip 702 can also access the raw data generated by host chip 706 and stored in external memory 708, for example, using direct memory access (DMA). Baseband chip 702 can first encode the raw data (e.g., through source coding and / or channel coding) and use any suitable modulation technique, such as multi-phase pre-shared key (MPSK) modulation or quadrature amplitude modulation (QAM) modulation. Baseband chip 702 can perform any other function, such as symbol or layer mapping, to convert the raw data into a signal that can be used to modulate the carrier frequency for transmission. In the uplink, baseband chip 702 can send the modulated signal to RF chip 704. RF chip 704, via a transmitter (Tx), can convert the modulated signal in digital form into an analog signal, i.e., an RF signal, and perform any suitable front-end RF functions, such as filtering, up-conversion, or sampling rate conversion. Antenna 710 (e.g., antenna array) can transmit radio frequency signals provided by the transmitter of radio frequency chip 704.
[0085] In the downlink, antenna 710 can receive radio frequency (RF) signals and transmit them to the receiver (Rx) of RF chip 704. RF chip 704 can perform any suitable front-end RF functions, such as filtering, down-conversion, or sampling rate conversion, and convert the RF signal into a low-frequency digital signal (baseband signal) that can be processed by baseband chip 702. In the downlink, baseband chip 702 can demodulate and decode the baseband signal to extract raw data that can be processed by host chip 706. Baseband chip 702 can perform additional functions such as error checking, demapping, channel estimation, and descrambling. The raw data provided by baseband chip 702 can be directly sent to host chip 706 or stored in external memory 708.
[0086] Figure 7 The baseband chip 702 in the middle can correspond to Figure 8 The baseband chip 802 is used in this example. The baseband chip 702 can achieve... Figure 1 The protocol stack shown includes the MAC layer, RLC layer, and PDCP layer. Similarly, Figure 7 The host chip 706 in the middle can correspond to Figure 8 The host chip is 804. Similarly, Figure 7 The external memory 708 in the memory can correspond to Figure 8 External memory 806.
[0087] Figure 8 A detailed block diagram of a baseband chip 802 illustrating an example of L2 uplink data processing implemented using L2 circuitry 808 and MCU 810 according to certain embodiments of the present disclosure is shown. In some embodiments, L2 circuitry 808 includes service data adaptation protocol (SDAP) circuitry 820, PDCP circuitry 822, RLC circuitry 824, and MAC circuitry 826. As described above, PDCP circuitry 822 may correspond to... Figure 1 The PDCP layer in the circuit, and the RLC circuit 824 and MAC circuit 826 can similarly correspond to the PDCP layer in the RLC layer, and the ... in the RLC layer, and the MAC circuit 826 in the RLC layer, and the MAC circuit 826 in the RLC layer, and the MAC circuit 824 in the RLC layer, Figure 1 The RLC layer and MAC layer in the L2 user plane. In some embodiments, each of the SDAP circuit 820, PDCP circuit 822, RLC circuit 824, and MAC circuit 826 is an integrated circuit (IC) specifically designed to perform the functions of the corresponding layer in the L2 user plane. For example, each of the SDAP circuit 820, PDCP circuit 822, RLC circuit 824, and MAC circuit 826 may be an application-specific integrated circuit (ASIC), which is customized for a specific purpose rather than intended for general-purpose use, and is therefore known for its high speed, small die size, and low power consumption compared to general-purpose processors. As an alternative, a general-purpose processor, such as a microcontroller unit (MCU) 810, can implement, for example, Figure 1 The PDCP layer, RLC layer, and MAC layer are shown.
[0088] Device 800 can be Figure 5 Any suitable node in the wireless network 500. For example, user equipment 510 or access node 520 (e.g., a base station including an eNB in LTE or a gNB in NR). Figure 8 As shown, device 800 may include a baseband chip 802, a host chip 804, an external memory 806, and a main bus 838 (also called a "system bus") operatively coupled to the baseband chip 802, host chip 804, and external memory 806. That is, the baseband chip 802, host chip 804, and external memory 806 can exchange data via the main bus 838. The baseband chip 802 can implement... Figure 1 , Figure 2 , Figure 3 and Figure 4 The method shown and Figure 1The architecture is shown in the diagram. For example, the SDAP circuit 820 can be configured, alone or with the MCU 810, to execute a mini token bucket scheme before passing data to the PDCP circuit 822. Other implementations are also permitted. The SDAP circuit 820 can also access and utilize external memory 806 and local memory 814 using, for example, the main bus 838.
[0089] like Figure 8 As shown, the baseband chip 802 may also include multiple direct memory access (DMA) channels, including a first DMA channel (DMA CH1) 816 and a second DMA channel (DMA CH2) 818. Each DMA channel 816 or 818 allows certain L2 circuitry 808 to access external memory 806 directly and independently of the host chip 804. In some embodiments, DMA channels 816 and 818 may include a DMA controller and any other suitable input / output (I / O) circuitry. Figure 8 As shown, the baseband chip 802 may also include a local memory 814, such as on-chip memory in the baseband chip 802. The local memory 814 is distinct from the external memory 806, which is off-chip memory not present in the baseband chip 802. In some embodiments, the local memory 814 includes one or more L1, L2, L3, or L4 caches. The L2 circuit 808 can also access the local memory 814 via the main bus 838.
[0090] like Figure 8 As shown, the baseband chip 802 may further include a local bus 840. In some embodiments, the MCU 810 is operatively coupled to the L2 circuit 808 and the main bus 838 via the local bus 840.
[0091] Referring to L2 circuit 808, L2 circuit 808 can be configured to provide L1 (Layer 1) transport blocks (as outputs of L2 circuit 808) in series and to provide L3 data packets (as inputs of L2 circuit 808) to the L1 transport blocks. In some embodiments, L2 circuit 808 is configured to pass data through each layer of L2 circuit 808 without storing the data in external memory 806. Data can flow from upper layers to lower layers in L2 (e.g., PDCP circuit 822, RLC circuit 824, and MAC circuit 826).
[0092] like Figure 8As shown, the MAC-PHY interface 830 is operatively coupled to a cascaded control buffer 828 and configured to provide L1 transport blocks to L1 (e.g., the PHY layer). The operation of the MAC-PHY interface 830 can be controlled based on a set of interface commands from the MCU 810. Depending on scheduling and modulation, each L1 transport block may contain data from the previous radio subframe, which has multiple or partial packets. Each L1 transport block may correspond to a MAC PDU and include a payload (e.g., with encrypted data) and multiple headers (e.g., MAC header, RLC header, and PDCP header).
[0093] like Figure 8 As shown, the serial control buffer 828 is operatively coupled to the MAC-PHY interface 830 and configured to store L1 transport blocks transmitted by the MAC-PHY interface 830. The serial control buffer 828 may be a separate physical memory component dedicated to L2 uplink data processing or part of local memory 814 (e.g., a logical partition thereof). The L2 circuitry 808 in the baseband chip 802 can perform L2 uplink data processing in a serial manner without accessing external memory 806.
[0094] like Figure 8 As shown, MAC circuit 826 can be operatively coupled to the series control buffer 828 and RLC circuit 824, and is configured to prepare the MAC header for the L1 transfer block to be stored in the series control buffer 828. The MAC header prepared by MAC circuit 826 can be controlled based on a set of MAC commands from MCU 810.
[0095] like Figure 8 As shown, the RLC circuit 824 can be operatively coupled to the MAC circuit 826 and the PDCP circuit 822, and is configured to prepare the RLC header of the L1 transport block for the MAC circuit 826. The preparation of the RLC header can be controlled based on a set of RLC commands from the MCU 810.
[0096] like Figure 8 As shown, the PDCP circuit 822 can be operatively coupled to the RLC circuit 824 and the SDAP circuit 820, and is configured to prepare the PDCP header of the L1 transport block for supply to the RLC circuit 824. The preparation of the PDCP header can be controlled based on a set of PDCP commands from the MCU 810.
[0097] According to one aspect of this disclosure, a method for packet preparation for uplink transmission may include: determining a Quality of Service (QoS) identifier associated with a QoS flow by a user equipment (UE). The method further includes: mapping the QoS identifier to a group token level by the UE. The method also includes: processing the QoS flow by the UE based on the group token level.
[0098] In some embodiments, the determination can be performed for the quality of service flow during the quality of service flow setup.
[0099] In some embodiments, the quality of service identifier may be a fifth-generation (5G) quality of service identifier.
[0100] In some embodiments, the mapping may include calculating the group token level based on multiple attributes of the quality of service flow.
[0101] In some embodiments, the plurality of attributes may include at least one of the priority level, resource type, or packet delay budget of the quality of service flow level.
[0102] In some embodiments, each of the plurality of attributes may be weighted individually when calculating the group token level.
[0103] In some embodiments, the method may further include assigning a maximum priority and an infinite bucket size to the highest priority queue.
[0104] In some embodiments, the process may include sorting the Quality of Service (QoS) streams according to priority access based on the group token level.
[0105] In some embodiments, the method may further include receiving an authorization for uplink communication. The authorization may include an authorization size in bytes. The method may further include allocating the authorization size in bytes across multiple logical channels. The method may additionally include allocating the authorization size in bytes among multiple Quality of Service (QoS) flows that include the QoS flow. The allocation of the authorization size in bytes among the multiple QoS flows may be performed based on individual group token levels of the respective QoS flows.
[0106] In some embodiments, the authorized size for allocating the bytes among the plurality of Quality of Service flows can be performed on a per-logical-channel basis.
[0107] In some embodiments, the authorized size for allocating the bytes among the plurality of Quality of Service (QoS) flows may include calculating the number of bytes for each group token level based on the sum of the group token levels used for all the plurality of QoS flows.
[0108] In some embodiments, the authorization size for allocating the bytes among the plurality of Quality of Service (QoS) flows may further include proportionally allocating mini token buckets among the plurality of QoS flows.
[0109] In some embodiments, the authorized size for allocating the bytes among the plurality of quality of service flows may further include allocating unused bytes from higher-priority quality of service flow buckets to lower-priority quality of service flow buckets.
[0110] In some embodiments, the method may further include dequeuing data from each of the plurality of quality of service streams in order of the respective group token levels.
[0111] In some embodiments, allocating the authorized size of the bytes across the plurality of logical channels includes allocating the authorized size of the bytes among the plurality of quality of service flows in the first logical channel, and then allocating the remaining authorized bytes from the first logical channel to the next logical channel.
[0112] According to another aspect of this disclosure, an apparatus for packet preparation for uplink transmission may include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code may be configured, using the at least one processor, to cause the apparatus to at least determine a Quality of Service (QoS) identifier associated with a QoS flow. The at least one memory and the computer program code may also be configured, using the at least one processor, to cause the apparatus to at least map the QoS identifier to a group token level. The at least one memory and the computer program code may also be configured, using the at least one processor, to cause the apparatus to process the QoS flow at least according to the group token level.
[0113] In some embodiments, the at least one memory and the computer program code may be configured to utilize the at least one processor to enable the device to map the quality of service identifier to the group token level by calculating the group token level based on multiple attributes of the quality of service stream.
[0114] In some embodiments, the at least one memory and the computer program code may be further configured to utilize the at least one processor to enable the device to receive at least an authorization for uplink communication, the authorization including an authorization size in bytes. The at least one memory and the computer program code may also be further configured to utilize the at least one processor to enable the device to allocate the authorization size in bytes at least across multiple logical channels. The at least one memory and the computer program code may be additionally configured to utilize the at least one processor to enable the device to allocate the authorization size in bytes at least among multiple Quality of Service (QoS) flows including the QoS flow. The allocation of the authorization size in bytes among the multiple QoS flows may be performed based on each group token level of each QoS flow.
[0115] In some embodiments, the at least one memory and the computer program code may be further configured to use the at least one process to dequeue data from each of the plurality of quality of service streams at least in the order of the respective group token levels.
[0116] In some embodiments, the at least one memory and the computer program code are configured to utilize at least one processor to enable the means to allocate the authorized size of the bytes across the plurality of logical channels, at least by allocating the authorized size of the bytes among the plurality of quality of service streams in a first logical channel, and then by allocating the remaining authorized bytes from the first logical channel to the next logical channel.
[0117] According to another aspect of this disclosure, a non-transitory computer-readable medium may be encoded with instructions that, when executed by a processor, cause the processor to perform at least one process for packet preparation for uplink transmission. The process may include: determining a Quality of Service (QoS) identifier associated with a QoS flow by a user equipment (UE). The process may further include: mapping the QoS identifier to a group token level by the UE. The process may also include: processing the QoS flow by the UE according to the group token level.
[0118] According to another aspect of this disclosure, the baseband chip for packet preparation for uplink transmission may include a service data adaptation protocol circuit, a packet data aggregation protocol circuit, and a media access control circuit. The service data adaptation protocol circuit may be configured to determine a quality of service identifier associated with a quality of service stream, map the quality of service identifier to a group token level, process the quality of service stream according to the group token level, and provide the quality of service stream to the packet data aggregation protocol circuit for transmission to the media access control circuit for transmission over physical layer circuitry.
[0119] The foregoing description of specific embodiments will thus reveal the general features of this disclosure, enabling others to readily modify and / or adapt these specific embodiments for various applications without departing from the general concept of this disclosure, by applying knowledge within the skill of the art, without undue experimentation. Therefore, based on the teachings and guidance provided herein, such modifications and adaptations are intended to fall within the meaning and scope of equivalents of the disclosed embodiments. It should be understood that the wording or terminology herein is for descriptive purposes and not for limitation, and that the wording or terminology of this specification will be interpreted by those skilled in the art based on the teachings and guidance.
[0120] The embodiments of this disclosure have been described above using functional building blocks that illustrate the implementation of specific functions and their relationships. For ease of description, the boundaries of these functional building blocks are arbitrarily defined herein. Alternative boundaries can be defined as long as the specific functions and their relationships are properly executed.
[0121] The summary and abstract may set forth one or more exemplary embodiments of the present disclosure as conceived by the inventors, but not all exemplary embodiments, and therefore are not intended to limit the present disclosure and the appended claims in any way.
[0122] Various functional blocks, modules, and steps have been disclosed above. The specific arrangements provided are illustrative and not limiting. Therefore, functional blocks, modules, and steps can be reordered or combined in ways different from the examples provided above. Similarly, some embodiments include only a subset of functional blocks, modules, and steps, and any such subset is permitted.
[0123] The breadth and scope of this disclosure should not be limited by any of the exemplary embodiments described above, but should be determined solely by the appended claims and their equivalents.
Claims
1. A method for packet preparation for uplink transmission, comprising: determining, by a user equipment, a quality of service identifier associated with a quality of service flow; mapping, by the user equipment, the quality of service identifier to a group token level, wherein the mapping comprises calculating the group token level based on a plurality of attributes of the quality of service flow, the plurality of attributes comprising a priority level of the quality of service flow, a resource type, and a packet delay budget, each of the plurality of attributes being individually weighted when calculating the group token level, wherein the mapping is flexibly adjustable by the user equipment, either statically or dynamically at runtime, to meet performance requirements of an application; and processing, by the user equipment, the quality of service flow according to the group token level.
2. The method of claim 1, wherein, The determining is performed for the quality of service flow during a quality of service flow setup.
3. The method of claim 1, wherein, The quality of service identifier comprises a fifth generation, 5G, quality of service identifier.
4. The method of claim 1, further comprising: assigning a highest priority queue a maximum priority and an unlimited bucket size.
5. The method of claim 1, further comprising: receiving a grant for uplink communication, wherein the grant comprises a granted size of bytes; allocating the granted size of bytes across a plurality of logical channels; and allocating the granted size of bytes among a plurality of quality of service flows including the quality of service flow, wherein allocating the granted size of bytes among the plurality of quality of service flows is performed based on individual group token levels of individual quality of service flows.
6. The method of claim 5, wherein, Allocating the granted size of bytes among the plurality of quality of service flows is performed on a per logical channel basis.
7. The method of claim 5, wherein, Allocating the granted size of bytes among the plurality of quality of service flows comprises calculating a number of bytes per group token level based on a sum of group token levels for all of the plurality of quality of service flows.
8. The method of claim 7, wherein, Allocating the granted size of bytes among the plurality of quality of service flows further comprises proportionally allocating mini token buckets among the plurality of quality of service flows.
9. The method of claim 8, wherein, Allocating the granted size of bytes among the plurality of quality of service flows further comprises allocating unused grants from higher priority quality of service flow buckets to lower priority quality of service flow buckets.
10. The method of claim 5, further comprising: dequeueing data from each of the plurality of quality of service flows in order of individual group token levels.
11. The method of claim 5, wherein, Allocating the granted size of bytes across the plurality of logical channels comprises, after allocating the granted size of bytes among the plurality of quality of service flows in a first logical channel, allocating a byte size of grants remaining from the first logical channel to a next logical channel.
12. A user equipment for packet preparation for uplink transmission, comprising: at least one processor; and at least one memory including computer program code, wherein the at least one memory and the computer program code are configured to, with the at least one processor, cause the user equipment at least to: determine a quality of service identifier associated with a quality of service flow; mapping the quality of service identifier to a group token level, wherein the mapping includes calculating the group token level based on a plurality of attributes of the quality of service flow, the plurality of attributes including a priority of a level of the quality of service flow, a resource type, and a packet delay budget, each of the plurality of attributes being individually weighted when calculating the group token level, wherein the mapping is flexibly adjustable by the user equipment at static setup or dynamic runtime to meet performance requirements of an application; and processing the quality of service flow according to the group token level.
13. The user equipment of claim 12, wherein, The at least one memory and the computer program code are further configured to, with the at least one processor, cause the user equipment at least to: receive a grant for uplink communication, wherein the grant includes a grant size of bytes; allocate the grant size of bytes across a plurality of logical channels; and allocate the grant size of bytes among a plurality of quality of service flows including the quality of service flow, wherein allocating the grant size of bytes among the plurality of quality of service flows is performed based on individual group token levels of individual quality of service flows.
14. The user equipment of claim 13, wherein, The at least one memory and the computer program code are further configured to, with the at least one processor, cause the user equipment at least to: dequeue data from each of the plurality of quality of service flows in order of individual group token levels.
15. The user equipment of claim 13, wherein, The at least one memory and the computer program code are configured to, with the at least one processor, cause the user equipment at least to allocate the grant size of bytes across the plurality of logical channels by, after allocating the grant size of bytes among the plurality of quality of service flows in a first logical channel, allocating grant bytes remaining from the first logical channel to a next logical channel.
16. A non-transitory computer readable medium encoded with instructions that, when executed by a processor of a user equipment, cause the processor to perform at least a process for packet preparation for uplink transmission, the process comprising: determining a quality of service identifier associated with a quality of service flow; mapping the quality of service identifier to a group token level, wherein the mapping includes calculating the group token level based on a plurality of attributes of the quality of service flow, the plurality of attributes including a priority of a level of the quality of service flow, a resource type, and a packet delay budget, each of the plurality of attributes being individually weighted when calculating the group token level, wherein the mapping is flexibly adjustable by the processor of the user equipment at static setup or dynamic runtime to meet performance requirements of an application; and processing the quality of service flow according to the group token level.
17. A baseband chip for packet preparation for uplink transmission, applied to a user equipment, comprising: a service data adaptation protocol (SDAP) circuit; a packet data convergence protocol (PDCP) circuit; and a medium access control (MAC) circuit, wherein the SDAP circuit is configured to: determine a quality of service identifier associated with a quality of service flow; mapping the quality of service identifier to a group token level, wherein the mapping includes calculating the group token level based on a plurality of attributes of the quality of service flow, the plurality of attributes including a priority of a level of the quality of service flow, a resource type, and a packet delay budget, each of the plurality of attributes being individually weighted when calculating the group token level, wherein the mapping is flexibly adjustable by the user equipment at static setup or dynamic runtime to meet performance requirements of an application; and processing the quality of service flow according to the group token level. mapping the quality of service identifier to a group token level, wherein the mapping includes calculating the group token level based on a plurality of attributes of the quality of service flow, the plurality of attributes including a priority of a class of the quality of service flow, a resource type, and a packet delay budget, each of the plurality of attributes being individually weighted in calculating the group token level, wherein the mapping is flexibly adjustable, either statically or dynamically at runtime, to meet performance requirements of an application; processing the quality of service flow according to the group token level; and providing the quality of service flow to the PDCP circuitry for delivery to the MAC circuitry for transmission by physical layer circuitry.
Citation Information
Patent Citations
Message processing method and device based on token buckets
CN104079499A