Login| Sign Up| Help| Contact|

Patent Searching and Data


Title:
HYPER FRAME NUMBER HANDLING MECHANISMS AND METHODS FOR EARLY START PACKET PROCESSING
Document Type and Number:
WIPO Patent Application WO/2022/197288
Kind Code:
A1
Abstract:
Embodiments of apparatus and method for data packet processing are disclosed. In one example, a method for processing data packets in a transceiver can include receiving a plurality of data packets at a packet data convergence protocol layer. The method can also include determining whether a hyper frame number of each data packet of the plurality of data packets can be accurately identified prior to deciphering. The method can further include evaluating the hyper frame number before deciphering only when the hyper frame number can be accurately identified prior to deciphering.

Inventors:
HONG HAUSTING (US)
LOW SU-LIN (US)
MA TIANAN (US)
LI JIANZHOU (US)
LEE CHUN-I (US)
KOVOOR SHEETHAL (US)
Application Number:
PCT/US2021/022635
Publication Date:
September 22, 2022
Filing Date:
March 16, 2021
Export Citation:
Click for automatic bibliography generation   Help
Assignee:
ZEKU INC (US)
International Classes:
H04W80/02; H04W12/10; H04W28/06
Foreign References:
US20140112157A12014-04-24
US20150280905A12015-10-01
US20140098797A12014-04-10
EP2785091A12014-10-01
US20200305225A12020-09-24
Attorney, Agent or Firm:
ZOU, Zhiwei (US)
Download PDF:
Claims:
WHAT IS CLAIMED IS:

1. A method for processing data packets in a transceiver, the method comprising: receiving a plurality of data packets at a packet data convergence protocol layer; determining whether a hyper frame number of each data packet of the plurality of data packets can be accurately identified prior to deciphering; and evaluating the hyper frame number before deciphering only when the hyper frame number can be accurately identified prior to deciphering.

2. The method of claim 1 , wherein the determining is based on a sequence number of each data packet of the plurality of data packets.

3. The method of claim 2, wherein the determining comprises assigning the sequence number to one of a plurality of zones and evaluating the hyper frame number based on the zone in which the sequence number is assigned.

4. The method of claim 1, wherein the determining is based on comparing a sequence number to a window size.

5. The method of claim 1, wherein evaluating the hyper frame number comprises maintaining a current hyper frame number or incrementing or decrementing the current hyper frame number by one.

6. The method of claim 1, further comprising: processing the plurality of data packets according to respective hyper frame numbers as evaluated.

7. The method of claim 1, further comprising: evaluating the hyper frame number after deciphering only when the hyper frame number cannot be accurately identified prior to deciphering.

8. An apparatus for processing data packets in a transceiver, the apparatus 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 transceiver at least to: receive a plurality of data packets at a packet data convergence protocol layer; determine whether a hyper frame number of each data packet of the plurality of data packets can be accurately identified prior to deciphering; and evaluate the hyper frame number before deciphering only when the hyper frame number can be accurately identified prior to deciphering.

9. The apparatus of claim 8, wherein the determining is based on a sequence number of each data packet of the plurality of data packets.

10. The apparatus of claim 9, wherein the determining comprises assigning the sequence number to one of a plurality of zones and evaluating the hyper frame number based on the zone in which the sequence number is assigned.

11. The apparatus of claim 8, wherein the determining is based on comparing a sequence number to a window size.

12. The apparatus of claim 8, wherein evaluating the hyper frame number comprises maintaining a current hyper frame number or incrementing or decrementing the current hyper frame number by one.

13. The apparatus of claim 8, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the transceiver at least to process the plurality of data packets according to respective hyper frame numbers as evaluated.

14. The apparatus of claim 8, wherein the at least one memory and the computer program code are further configured to, with the at least one processor, cause the transceiver at least to evaluate the hyper frame number after deciphering only when the hyper frame number cannot be accurately identified prior to deciphering. 15. A non-transitory computer-readable medium encoded with instructions that, when executed in a processor, perform a process for processing data packets in a transceiver, the process comprising: receiving a plurality of data packets at a packet data convergence protocol layer; determining whether a hyper frame number of each data packet of the plurality of data packets can be accurately identified prior to deciphering; and evaluating the hyper frame number before deciphering only when the hyper frame number can be accurately identified prior to deciphering.

16. The non-transitory computer-readable medium of claim 15, wherein the determining is based on a sequence number of each data packet of the plurality of data packets.

17. The non-transitory computer-readable medium of claim 16, wherein the determining comprises assigning the sequence number to one of a plurality of zones and evaluating the hyper frame number based on the zone in which the sequence number is assigned.

18. The non-transitory computer-readable medium of claim 15, wherein the determining is based on comparing a sequence number to a window size.

19. The non-transitory computer-readable medium of claim 15, wherein evaluating the hyper frame number comprises maintaining a current hyper frame number or incrementing or decrementing the current hyper frame number by one.

20. The non-transitory computer-readable medium of claim 15, the process further comprising: processing the plurality of data packets according to respective hyper frame numbers as evaluated.

21. The non-transitory computer-readable medium of claim 15, the process further comprising: evaluating the hyper frame number after deciphering only when the hyper frame number cannot be accurately identified prior to deciphering.

Description:
HYPER FRAME NUMBER HANDLING MECHANISMS AND METHODS FOR EARLY START PACKET PROCESSING

BACKGROUND

[0001] Embodiments of the present disclosure relate to apparatuses and methods for wireless communication.

[0002] Wireless communication systems are widely deployed to provide various telecommunication services such as telephony, video, data, messaging, and broadcasts. In wireless communications, there may be uplink communications from a user equipment to a base station and downlink communications from the base station to the user equipment. In both uplink and downlink, packets may traverse a variety of layers, including the packet data convergency protocol (PDCP) layer. The PDCP layer may be responsible for the transfer of user plane and control plane data. The PDCP layer may also be responsible for header compression, ciphering, and integrity protection. The PDCP layer may keep track of which packets have been received and may identify gaps in received packets. A count value may be used to keep track of the most recently received packet.

SUMMARY

[0003] Embodiments of apparatus and method for data packet processing are disclosed herein.

[0004] In one example, a method for processing data packets in a transceiver can include receiving a plurality of data packets at a packet data convergence protocol layer. The method can also include determining whether a hyper frame number of each data packet of the plurality of data packets can be accurately identified prior to deciphering. The method can further include evaluating the hyper frame number before deciphering only when the hyper frame number can be accurately identified prior to deciphering.

[0005] In another example, an apparatus for processing data packets in a transceiver can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the transceiver at least to receive a plurality of data packets at a packet data convergence protocol layer. The at least one memory and the computer program code can also be configured to, with the at least one processor, cause the transceiver at least to determine whether a hyper frame number of each data packet of the plurality of data packets can be accurately identified prior to deciphering. The at least one memory and the computer program code can further be configured to, with the at least one processor, cause the transceiver at least to evaluate the hyper frame number before deciphering only when the hyper frame number can be accurately identified prior to deciphering.

[0006] In a further example, a non-transitory computer-readable medium can be encoded with instructions that, when executed in a processor, perform a process for processing data packets in a transceiver. The process can include receiving a plurality of data packets at a packet data convergence protocol layer. The process can also include determining whether a hyper frame number of each data packet of the plurality of data packets can be accurately identified prior to deciphering. The process can further include evaluating the hyper frame number before deciphering only when the hyper frame number can be accurately identified prior to deciphering.

BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments of the present disclosure and, together with the description, further serve to explain the principles of the present disclosure and to enable a person skilled in the pertinent art to make and use the present disclosure.

[0008] FIG. 1 illustrates a fifth-generation (5G) data plane architecture.

[0009] FIG. 2 illustrates possible HFN situations, which may be addressed by some embodiments of the present disclosure.

[0010] FIG. 3 illustrates more detail regarding the top portion of FIG. 2.

[0011] FIG. 4 illustrates more detail regarding the bottom portion of FIG. 2.

[0012] FIG. 5A and 5B are modified versions of respectively the top and bottom portions of FIG. 2.

[0013] FIG. 6A illustrates a pseudo-code of a process for evaluating HFN during a first pass, according to some embodiments of the present disclosure.

[0014] FIG. 6B illustrates a pseudo-code of a process for evaluating HFN at a second pass, according to some embodiments of the present disclosure.

[0015] FIG. 7 illustrates a method, according to some embodiments of the present disclosure. [0016] FIG. 8 illustrates a block diagram of an apparatus including a baseband chip, a radio frequency chip, and a host chip, according to some embodiments of the present disclosure.

[0017] FIG. 9 illustrates an example node, in which some aspects of the present disclosure may be implemented, according to some embodiments of the present disclosure.

[0018] FIG. 10 illustrates an example wireless network, in which some aspects of the present disclosure may be implemented, according to some embodiments of the present disclosure. [0019] Embodiments of the present disclosure will be described with reference to the accompanying drawings.

DETAILED DESCRIPTION

[0020] Although specific configurations and arrangements are discussed, it should be understood that this is done for illustrative purposes only. A person skilled in the pertinent art will recognize that other configurations and arrangements can be used without departing from the spirit and scope of the present disclosure. It will be apparent to a person skilled in the pertinent art that the present disclosure can also be employed in a variety of other applications.

[0021] It is noted that references in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” “some embodiments,” “certain embodiments,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases do not necessarily refer to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of a person skilled in the pertinent art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

[0022] In general, terminology may be understood at least in part from usage in context.

For example, the term “one or more” as used herein, depending at least in part upon context, may be used to describe any feature, structure, or characteristic in a singular sense or may be used to describe combinations of features, structures or characteristics in a plural sense. Similarly, terms, such as “a,” “an,” or “the,” again, may be understood to convey a singular usage or to convey a plural usage, depending at least in part upon context. In addition, the term “based on” may be understood as not necessarily intended to convey an exclusive set of factors and may, instead, allow for existence of additional factors not necessarily expressly described, again, depending at least in part on context.

[0023] Various aspects of wireless communication systems will now be described with reference to various apparatus and methods. These apparatus and methods will be described in the following detailed description and illustrated in the accompanying drawings by various blocks, modules, units, components, circuits, steps, operations, processes, algorithms, etc. (collectively referred to as “elements”). These elements may be implemented using electronic hardware, firmware, computer software, or any combination thereof. Whether such elements are implemented as hardware, firmware, or software depends upon the particular application and design constraints imposed on the overall system.

[0024] The techniques described herein may be used for various wireless communication networks, such as code division multiple access (CDMA) system, time division multiple access (TDMA) system, frequency division multiple access (FDMA) system, orthogonal frequency division multiple access (OFDMA) system, single-carrier frequency division multiple access (SC- FDMA) system, and other networks. The terms “network” and “system” are often used interchangeably. A CDMA network may implement a radio access technology (RAT), such as Universal Terrestrial Radio Access (UTRA), CDMA 2000, etc. A TDMA network may implement a RAT, such as Global System for Mobile communication (GSM). An OFDMA network may implement a RAT, such as Long-Term Evolution (LTE) or New Radio (NR). The techniques described herein may be used for the wireless networks and RATs mentioned above, as well as other wireless networks and RATs.

[0025] In typical cellular modems, the data plane architecture of the modem may be statically configured for the maximum expected throughput processing, including processors that are not scalable. In some cellular modems, processing units that are specific to one or two layers may be implemented. As such, the processing units may not be proportionally scalable to optimize the power and performance of the modem, to support either high throughput or low latency low throughput applications.

[0026] FIG. 1 illustrates a 5G data plane architecture. As shown in FIG. 1, in a 5G cellular wireless modem, the UE data stack can include layer two (L2) layers of medium access control (MAC), radio link control (RLC), packet data convergence protocol, and service data adaptation protocol (SDAP), and L3/L4 layers. The UE data stack can process the internet protocol (IP) layer functions. [0027] FIG. 1 illustrates a typical structure of data stack processing architecture for a 5G cellular wireless modem. Separate vertical processing stacks, a downlink (DL) processing engine 110 and an uplink (UL) processing engine 120, are usually put together in one processing engine, in this example, data plane processor 105, for the DL data stack and UL data stack, which could be one processor core or separate cores for each layer. In FIG. 1, a single DL core 115 and a single UL core 125 are illustrated by way of example.

[0028] Within the protocol stacks (whether considering the DL data stack or the UL data stack), the MAC layer can interface with the physical (PHY) layer to transfer DL and UL data, and the L3/L4 layer can interface with the AP/Host 130. Packet data can be transferred from shared memory (not shown) throughout the data stack, which could be local or external memory.

[0029] In a typical 5G carrier aggregation (CA) configuration, multiple Component

Carriers (CCs) can be aggregated for a MAC entity, which presents challenging processing requirements for the data stack to process multiple Transport Blocks (TBs), one from each CC, in one time slot. This is processed for time slot durations from 1ms (which implies 15kHz subcarrier spacing (SCS)), 0.5ms (which implies 30kHz SCS), 0.25ms (which implies 60kHz SCS), and up to 0.125ms (which implies 120kHz SCS).

[0030] At the DL, the MAC layer can decode and route TBs from each CC to logical channels up the data stack processing chain. The DL data stack can include packet processing and radio link recovery mechanisms at RLC, PDCP, SDAP, and L4/L4 layers.

[0031] At the UL, arriving data packets from AP/Host 130 can be processed by L3/L4,

PDCP, RLC layers and put into logical channel (LC) queues. Upon grant arrival from each CC, the MAC layer can multiplex the data to be sent out for each TB on each CC.

[0032] As shown in FIG. 1 , there can be multiple CCs. For example, one component carrier

(in this example, CC1) can be for a primary cell of a secondary cell group (SCG) (PScell). The remaining component carriers may be for other cells of the SCG. It may be valuable for the data stack to process multiple TBs from multiple CC efficiently and effectively for all traffic loads. [0033] In the processing of TBs, one consideration may be the re-ordering of packets. In some embodiments, hyper frame number (HFN) is a state variable. More particularly, HFN can be the most significant bits of a unique 32-bit RCVD_COUNT of a PDCP data packet data unit (PDU) received from lower layers to go through ciphering/deciphering, integrity protection/verification. [0034] More particularly, RCVD_COUNT can be a unique 32-bit count value that can be used to identify a packet. This count value can be made up of HFN at the most significant bits with PDCP sequence number (SN) obtained from the header of PDCP Data PDU at the lower bits. The number of bits in the PDCP SN can be 12 or 18 bits. The bit length may depend on the configuration for a radio bearer. HFN can be 20 or 14 bits in view of the 32-bit total value and the 12-bit or 18-bit PDCP SN.

[0035] HFN can be used in a network to cipher and/or provide integrity protection. For example, any PDU with an HFN should match with the one calculated at UE at DL. A mismatch can result in a failure at integrity verification, if such verification is configured. A mismatch can also result in compromised deciphering at the data part of the PDU, though not the PDCP header because the PDCP header is not subject to be ciphered.

[0036] To increase secrecy, HFN may not be exchanged over-the-air. Accordingly, it can be the task for both the UE and the network equipment to calculate HFN at the receiving end before deciphering and/or integrity verification. Some embodiments provide a way of calculating HFN for an early-start packet processing scheme at the downlink.

[0037] Early-start packet processing can refer to starting packet processing earlier than the result of transport block cyclic redundancy check (TB-CRC) being made known. Calculation of HFN before the TB-CRC result is known may need some embodiments of the present disclosure to prevent possible erroneous packets deciphering, integrity verification due to a potentially outdated RX_DELIV in use. The potentially outdated RX_DELIV in use may affect the value of RCVD_COUNT, and thus skew the result of deciphering/integrity verification.

[0038] Some embodiments provide a two-pass approach to HFN determination· The approach can include an HFN calculation scheme that determines whether a data PDU should proceed to deciphering/integrity check at a first pass or defer to the second pass. The approach can also include an events sequence flow that can follow up at a second pass to complete the entire function.

[0039] If an early-start solution is employed where RX_DELIV is used at first pass to calculate RCVD_COUNT for all Data PDU’s to complete deciphering/integrity check, then the result may be a wrong RCVD_COUNT.

[0040] Some embodiments may provide a robust, high-performance, low-cost, and low- power-consumption 5G modem data plane design.

[0041] HFN can be the most significant bits (MSBs) of a 32-bit count. One way to visualize this is to imagine HFN as representing page numbers partition the entire space into equal-sized pages, where the size of each page is the maximum PDCP SN. [0042] In the following example, an 18-bit PDCP SN is considered by way of example and not limitation.

[0043] A receiving window at a safe segment is considered anything between RX_DELIV and (RX_DELIV + 128). Any packet with RCVD_COUNT falling outside this window can be discarded. Since HFN is not part of the header, the UE can calculate to obtain the full RCVD_COUNT before this decision can be made.

[0044] FIG. 2 illustrates possible HFN situations, which may be addressed by some embodiments of the present disclosure. In section 5.2.2.1 of Third Generation Partnership Project (3GPP) Technical Specification (TS) 38.323, there is a set of formulas to show how HFN calculation should be done. For example, if RCVD_SN < SN(RX_DEFIV) - Window_Size (corresponding to Grey Area 1 in FIG. 2), then RCVD_HFN = HFN(RX_DEFIV) + 1 (in other words HFN of RX_DEFIV + 1), else if RCVD_SN >= SN(RX_DEFIV) + Window_Size: (corresponding to Grey Area 2 in FIG. 2) then RCVD_HFN = HFN(RX_DEFIV) - 1, else RCVD_HFN = HFN(RX_DEFIV) (corresponding to the fixed-size safe zone at 128K entries). [0045] In the example of FIG. 2, HFN=3 for current RX_DEFIV. SN of RX_DEFIV can be found either at the right half (top portion of FIG. 2) or left half (bottom portion of FIG. 2) of SN space. The early-start packet processing approach calls for deciphering/integrity check prior to the result of TB-CRC. Thus, RX_DEFIV at the first pass for this TB is obtained from prior TB that has the RX_DEFIV updated at its 2nd pass. This implies any impact of HFN calculation from the possible movement of RX_DEFIV due to the current TB is not considered throughout this pass. [0046] When considering the scope of impact from the alleged movement or advancement at current RX_DEFIV, note that the current RX_DEFIV can only advance for half of the SN space with respect to prior RX_DEFIV. Thus, the RX_DEFIV can wrap around when SN of RX_DEFIV hits the maximum number, which is 2047 (at 12-bit SN) or 131071 or 2 L 17 - 1 (at 18-bit SN). Nevertheless, the standard indicates HFN can be incremented by one for any incoming SN that fall into Grey Area 1 , which is deemed as an entry in Zone 1 for its full count representation, referred to as RCVD_COUNT. On the other hand, those are found in Grey Area 2 is deemed as in Zone 2 for its RCVD_COUNT, meaning HFN should be decremented by one.

[0047] FIG. 3 illustrates more detail regarding the top portion of FIG. 2. For the top portion of FIG. 2, SN (prior RX_DEFIV), denoted as B (see FIG. 3), can possibly move within Zone B or Grey Area 1 shown in FIG. 3. [0048] To find out what HFN is for an incoming SN evaluated under prior RX_DELIV (or

B) and current RX_DELIV or B’) at all possible zones including Zone B and Grey Area 1, the result can be as listed in Table 1. Table 1 : Comparison chart for HFN evaluation between prior and current RX_DELIV

[0049] The circled area of Table 1 is where current RX_DELIV and prior RX_DELIV may result in different HFNs for incoming SN, namely Zone C & D. The size of Zone C + Zone D equals the size of the Receive_Window.

[0050] FIG. 4 illustrates more detail regarding the bottom portion of FIG. 2. For the bottom portion of FIG. 2, SN(prior RX_DELIV) at the left half of HFN page 3 denoted as C, current RX_DELIV can possibly move within Green Zone, as shown in FIG. 4.

[0051] The HFN for an incoming SN evaluated under prior RX_DELIV (or C) and current

RX_DELIV (or C’) at all possible zones including Zone A and B, can be seen in Table 2. The circled area is where current RX_DELIV and prior RX_DELIV may have different HFNs for incoming SN, namely Zone C & Grey Area 2. A combination of these two zones can act as an exclusion of green zone within an HFN page in this scenario, which is also the size of a Recei ve_W indo w.

Table 2: Another comparison chart for HFN evaluation between prior and current RX_DELIV [0052] From the above, it can be seen that Zones C and D in FIG. 3 might produce discrepancies between HFN(prior RX_DELIV) and HFN(current RX_DELIV) when SN(prior RX_DELIV) is at the right half of an HFN page. Similarly, Zone C and Grey Area 2 in FIG. 4 might produce discrepancies between HFN(prior RX_DELIV) and HFN(current RX_DELIV) when SN(prior RX_DELIV) is at the left half of an HFN page. [0053] These discrepancies may arise from the uncertainty of the current RX_DELIV at the first pass because RX_DELIV cannot be updated before TB-CRC is confirmed. So, RX_DELIV used at this step can be different from the current RX_DELIV. Some embodiments of the present disclosure address this issue in order to produce a correct HFN for any incoming SN, no matter where the current RX_DELIV might be.

[0054] FIG. 5A and 5B are modified versions of respectively the top and bottom portions of FIG. 2. FIG. 5 A and 5B illustrate modifications to show where the zones that an incoming SN might evaluate an HFN different than one that it would have calculated had it used current RX_DEFIV. These are the zones that may need to be addressed for an early-start packet processing approach. SN arriving at the other zones may share the same HFN whether the HFN is calculated based on prior RX_DEFIV or current RX_DEFIV, so they do not pose an issue.

[0055] In FIGs. 5A and 5B, skip zones can be observed in both cases where SN of prior

RX_DEFIV is at either side. When the SN falls into skip zones 1, 2, or 3, uncertainties may be introduced into HFN evaluation with the possible movement of RX_DEFIV relative to the first pass. Thus, in those cases, some embodiments of the present disclosure call for a deferred deciphering/integrity check to the second pass when the RX_DEFIV gets updated as it progresses through this phase.

[0056] Thus, in some embodiments, the SNs that are not in skip zones may receive a security check at first pass to bring minimum latency to end-to-end performance. Meanwhile, the SNs that fall into skip zones can skip the security check during the first pass and only receive the security check at the second pass after RFC windows and duplicate the check process.

[0057] At the first pass, an incoming SN of a PDU can have its HFN evaluated through the logic shown in FIG. 6A. FIG. 6A illustrates a pseudo-code of a process for evaluating HFN during a first pass, according to some embodiments of the present disclosure. As shown in FIG. 6A, if the SN is in the right half of an HFN page, then if the SN is in grey area 1, HFN can be incremented by one, if the HFN is in a safe zone, the HFN can be used as is, and if the HFN is in a skip zone, HFN determination can be delayed to a second pass. Also shown in FIG. 6 A, when the SN is in the left half of the HFN page, then it can be determined whether the SN is in the safe zone (in which case the HFN can be used as is) or whether the SN is in one of the skip zones, in which case the HFN can be determined in the second pass.

[0058] FIG. 6B illustrates a pseudo-code of a process for evaluating HFN at a second pass, according to some embodiments of the present disclosure. As shown in FIG. 6B, once the processing progresses to the second pass, those SNs that were skipped at the first pass in the process illustrated in FIG. 6A can undergo a security check with HFN evaluated as described in section 5.2.2.1 of 3GPP TS 38.323 after checking with radio link control (RLC). This can provide a follow up to what was accomplished at the first pass.

[0059] Some embodiments may have various characteristics. For example, some embodiments may rely on early-start packet processing. Early-start processing can be observed through the latency associated with decoding PDUs from the physical layer appearing at L3. In early-start processing, such latency may be one transmission time interval (TTI) plus a fraction thereof. Otherwise, such processing may take approximately 2xTTI. On the other hand, some embodiments also avoid blindly applying early- state processing to all PDUs. As explained above, in some cases, early-start processing can result in packets being erroneously deciphered and ultimately being discarded. By contrast, some embodiments of the present disclosure may selectively delay the processing of specific SNs in cases where such errors could occur.

[0060] The above may be performed in the PDCP layer. The implementation can be done in hardware, software, or a combination thereof.

[0061] FIG. 7 illustrates a method according to some embodiments of the present disclosure. As shown in FIG. 7, a method for processing data packets in a transceiver can include, at 710, receiving a plurality of data packets at a packet data convergence protocol layer. These data packets may be received in a downlink process from lower layers of the protocol stack, as illustrated and discussed above with reference to FIG. 1.

[0062] The method can also include, at 720, determining whether a hyper frame number of each data packet of the plurality of data packets can be accurately identified prior to deciphering. The method can further include, at 730, evaluating the hyper frame number before deciphering only when the hyper frame number can be accurately identified prior to deciphering. This can also be referred to as determining the hyper frame number during the first pass, as described above. [0063] The determining can be based on a sequence number of each data packet of the plurality of data packets, as described above and illustrated in Figure 6A. For example, multiple comparisons to the sequence number can be used, as shown in the pseudo-code provided.

[0064] The determining can include assigning the sequence number to one of a plurality of zones and evaluating the hyper frame number based on the zone in which the sequence number is assigned. Example zones are shown in the code comments in FIGs. 6 A and 6B, as well as in FIGs. 2, 3, 4, 5 A, and 5B. The labeling of the zones can be varied without departing from the principles and teachings set forth herein.

[0065] The determining can be based on comparing a sequence number to a window size.

For example, it can be determined whether the sequence number is less than a previously verified sequence number plus a window size.

[0066] The evaluating of the hyper frame number can include maintaining a current hyper frame number (when a current number is 3, this could mean maintaining 3) or incrementing or decrementing the current hyper frame number by one (for example, determining that the hyper frame number should 2 or 4.

[0067] The method can additionally include, at 740, processing the plurality of data packets according to respective hyper frame numbers as evaluated.

[0068] The method can further include, at 750, evaluating the hyper frame number after deciphering only when the hyper frame number cannot be accurately identified prior to deciphering. This can be referred to as obtaining the HFN in the second pass, as described above. [0069] The software and hardware methods and systems disclosed herein, such as the methods illustrated in FIGs. 2 through 7, may be implemented by any suitable nodes in a wireless network. For example, FIGs. 8 and 9 illustrate respective apparatuses 800 and 900, and FIG. 10 illustrates an exemplary wireless network 1000, in which some aspects of the present disclosure may be implemented, according to some embodiments of the present disclosure.

[0070] FIG. 8 illustrates a block diagram of an apparatus 800 including a baseband chip

802, a radio frequency chip 804, and a host chip 806, according to some embodiments of the present disclosure. Apparatus 800 may be an example of any suitable node of wireless network 1000 in FIG. 10, such as user equipment 1002 or network node 1004. As shown in FIG. 8, apparatus 800 may include baseband chip 802, radio frequency chip 804, host chip 806, and one or more antennas 810. In some embodiments, baseband chip 802 is implemented by processor 902 and memory 904, and radio frequency chip 804 is implemented by processor 902, memory 904, and transceiver 906, as described below with respect to FIG. 9. In certain embodiments, baseband chip 802 may, in whole or in part, implement the systems and methods and generate and process the messages shown in FIGs. 2-7. For example, baseband chip 802 in a user equipment may perform the UE steps, generate the UE messages, and the like, respectively, in the uplink and downlink. Besides the on- chip memory (also known as “internal memory” or “local memory,” e.g., registers, buffers, or caches) on each chip 802, 804, or 806, apparatus 800 may further include an external memory 808 (e.g., the system memory or main memory) that can be shared by each chip 802, 804, or 806 through the system/main bus. Although baseband chip 802 is illustrated as a standalone SoC in FIG. 8, it is understood that in one example, baseband chip 802 and radio frequency chip 804 may be integrated as one SoC; in another example, baseband chip 802 and host chip 806 may be integrated as one SoC; in still another example, baseband chip 802, radio frequency chip 804, and host chip 806 may be integrated as one SoC, as described above.

[0071] In the uplink, host chip 806 may generate raw data and send it to baseband chip 802 for encoding, modulation, and mapping. As mentioned above, the data from host chip 806 may be associated with various IP flows. Baseband chip 802 may map those IP flows to quality of service flows and perform additional data plane management functions, as described above. Baseband chip 802 may also access the raw data generated by host chip 806 and stored in external memory 808, for example, using the direct memory access (DMA). Baseband chip 802 may first encode (e.g., by source coding and/or channel coding) the raw data and modulate the coded data using any suitable modulation techniques, such as multi-phase pre-shared key (MPSK) modulation or quadrature amplitude modulation (QAM). Baseband chip 802 may perform any other functions, 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 802 may send the modulated signal to radio frequency chip 804. Radio frequency chip 804, through the transmitter (Tx), may convert the modulated signal in the digital form into analog signals, i.e., radio frequency signals, and perform any suitable front-end radio frequency functions, such as filtering, up-conversion, or sample-rate conversion. Antenna 810 (e.g., an antenna array) may transmit the radio frequency signals provided by the transmitter of radio frequency chip 804.

[0072] In the downlink, antenna 810 may receive radio frequency signals and pass the radio frequency signals to the receiver (Rx) of radio frequency chip 804. Radio frequency chip 804 may perform any suitable front-end radio frequency functions, such as filtering, down-conversion, or sample-rate conversion, and convert the radio frequency signals into low-frequency digital signals (baseband signals) that can be processed by baseband chip 802. In the downlink, baseband chip 802 may demodulate and decode the baseband signals to extract raw data that can be processed by host chip 806. Baseband chip 802 may perform additional functions, such as error checking, de mapping, channel estimation, descrambling, etc. The raw data provided by baseband chip 802 may be sent to host chip 806 directly or stored in external memory 808. [0073] As shown in FIG. 9, a node 900 may include a processor 902, a memory 904, a transceiver 906. These components are shown as connected to one another by bus 908, but other connection types are also permitted. When node 900 is user equipment 1002, additional components may also be included, such as a user interface (UI), sensors, and the like. Similarly, node 900 may be implemented as a blade in a server system when node 900 is configured as core network element 1006. Other implementations are also possible.

[0074] Transceiver 906 may include any suitable device for sending and/or receiving data.

Node 900 may include one or more transceivers, although only one transceiver 906 is shown for simplicity of illustration. An antenna 910 is shown as a possible communication mechanism for node 900. Multiple antennas and/or arrays of antennas may be utilized. Additionally, examples of node 900 may communicate using wired techniques rather than (or in addition to) wireless techniques. For example, network node 1004 may communicate wirelessly to user equipment 1002 and may communicate by a wired connection (for example, by optical or coaxial cable) to core network element 1006. Other communication hardware, such as a network interface card (NIC), may be included as well.

[0075] As shown in FIG. 9, node 900 may include processor 902. Although only one processor is shown, it is understood that multiple processors can be included. Processor 902 may include microprocessors, microcontrollers, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), programmable logic devices (PLDs), state machines, gated logic, discrete hardware circuits, and other suitable hardware configured to perform the various functions described throughout the present disclosure. Processor 902 may be a hardware device having one or many processing cores. Processor 902 may execute software. Software shall be construed broadly to mean instructions, instruction sets, code, code segments, program code, programs, subprograms, software modules, applications, software applications, software packages, routines, subroutines, objects, executables, threads of execution, procedures, functions, etc., whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. Software can include computer instructions written in an interpreted language, a compiled language, or machine code. Other techniques for instructing hardware are also permitted under the broad category of software. Processor 902 may be a baseband chip, such as baseband chip 802 in FIG. 8. Node 900 may also include other processors, not shown, such as a central processing unit of the device, a graphics processor, or the like. Processor 902 may include internal memory (also known as local memory, not shown in FIG. 9) that may serve as memory for L2 data. Processor 902 may include a radio frequency chip, for example, integrated into a baseband chip, or a radio frequency chip may be provided separately. Processor 902 may be configured to operate as a modem of node 900, or may be one element or component of a modem. Other arrangements and configurations are also permitted.

[0076] As shown in FIG. 9, node 900 may also include memory 904. Although only one memory is shown, it is understood that multiple memories can be included. Memory 904 can broadly include both memory and storage. For example, memory 904 may include random-access memory (RAM), read-only memory (ROM), static RAM (SRAM), dynamic RAM (DRAM), ferro electric RAM (FRAM), electrically erasable programmable ROM (EEPROM), CD-ROM or other optical disk storage, hard disk drive (HDD), such as magnetic disk storage or other magnetic storage devices, Flash drive, solid-state drive (SSD), or any other medium that can be used to carry or store desired program code in the form of instructions that can be accessed and executed by processor 902. Broadly, memory 904 may be embodied by any computer-readable medium, such as a non-transitory computer-readable medium. The memory 904 can be the external memory 808 in FIG. 8. The memory 904 may be shared by processor 902 and other components of node 900, such as the unillustrated graphic processor or central processing unit.

[0077] As shown in FIG. 10, wireless network 1000 may include a network of nodes, such as a UE 1002, a network node 1004, and a core network element 1006. User equipment 1002 may be any terminal device, such as a mobile phone, a desktop computer, a laptop computer, a tablet, a vehicle computer, a gaming console, a printer, a positioning device, a wearable electronic device, a smart sensor, or any other device capable of receiving, processing, and transmitting information, such as any member of a vehicle to everything (V2X) network, a cluster network, a smart grid node, or an Intemet-of-Things (IoT) node. It is understood that user equipment 1002 is illustrated as a mobile phone simply by way of illustration and not by way of limitation.

[0078] Network node 1004 may be a device that communicates with user equipment 1002, such as a wireless access point, a base station (BS), a Node B, an enhanced Node B (eNodeB or eNB), a next-generation NodeB (gNodeB or gNB), a cluster master node, or the like. Network node 1004 may have a wired connection to user equipment 1002, a wireless connection to user equipment 1002, or any combination thereof. Network node 1004 may be connected to user equipment 1002 by multiple connections, and user equipment 1002 may be connected to other access nodes in addition to network node 1004. Network node 1004 may also be connected to other UEs. It is understood that network node 1004 is illustrated by a radio tower by way of illustration and not by way of limitation.

[0079] Core network element 1006 may serve network node 1004 and user equipment 1002 to provide core network services. Examples of core network element 1006 may include a home subscriber server (HSS), a mobility management entity (MME), a serving gateway (SGW), or a packet data network gateway (PGW). These are examples of core network elements of an evolved packet core (EPC) system, which is a core network for the LTE system. Other core network elements may be used in LTE and in other communication systems. In some embodiments, core network element 1006 includes an access and mobility management function (AMF) device, a session management function (SMF) device, or a user plane function (UPF) device, of a core network for the NR system. It is understood that core network element 1006 is shown as a set of rack-mounted servers by way of illustration and not by way of limitation.

[0080] Core network element 1006 may connect with a large network, such as the Internet

1008, or another IP network, to communicate packet data over any distance. In this way, data from user equipment 1002 may be communicated to other UEs connected to other access points, including, for example, a computer 1010 connected to Internet 1008, for example, using a wired connection or a wireless connection, or to a tablet 1012 wirelessly connected to Internet 1008 via a router 1014. Thus, computer 1010 and tablet 1012 provide additional examples of possible UEs, and router 1014 provides an example of another possible access node.

[0081] A generic example of a rack-mounted server is provided as an illustration of core network element 1006. However, there may be multiple elements in the core network including database servers, such as a database 1016, and security and authentication servers, such as an authentication server 1018. Database 1016 may, for example, manage data related to user subscription to network services. A home location register (HLR) is an example of a standardized database of subscriber information for a cellular network. Likewise, authentication server 1018 may handle authentication of users, sessions, and so on. In the NR system, an authentication server function (AUSF) device may be the specific entity to perform user equipment authentication. In some embodiments, a single server rack may handle multiple such functions, such that the connections between core network element 1006, authentication server 1018, and database 1016, may be local connections within a single rack.

[0082] Each of the elements of FIG. 10 may be considered a node of wireless network

1000. More detail regarding the possible implementation of a node is provided by way of example in the description of a node 900 in FIG. 9 above. Node 900 may be configured as user equipment 1002, network node 1004, or core network element 1006 in FIG. 10. Similarly, node 900 may also be configured as computer 1010, router 1014, tablet 1012, database 1016, or authentication server 1018 in FIG. 10.

[0083] In various aspects of the present disclosure, the functions described herein may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or encoded as instructions or code on a non-transitory computer-readable medium. Computer-readable media includes computer storage media. Storage media may be any available media that can be accessed by a computing device, such as node 900 in FIG. 9. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, HDD, such as magnetic disk storage or other magnetic storage devices, Flash drive, SSD, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a processing system, such as a mobile device or a computer. Disk and disc, as used herein, includes CD, laser disc, optical disc, digital versatile disk (DVD), and floppy disk where disks usually reproduce data magnetically, while discs reproduce data optically with lasers. Combinations of the above should also be included within the scope of computer-readable media. [0084] According to one aspect of the present disclosure, a method for processing data packets in a transceiver can include receiving a plurality of data packets at a packet data convergence protocol layer. The method can also include determining whether a hyper frame number of each data packet of the plurality of data packets can be accurately identified prior to deciphering. The method can further include evaluating the hyper frame number before deciphering only when the hyper frame number can be accurately identified prior to deciphering. [0085] In some embodiments, the determining can be based on a sequence number of each data packet of the plurality of data packets.

[0086] In some embodiments, the determining can include assigning the sequence number to one of a plurality of zones and evaluating the hyper frame number based on the zone in which the sequence number is assigned.

[0087] In some embodiments, the determining can be based on comparing a sequence number to a window size. [0088] In some embodiments, the evaluating the hyper frame number can include maintaining a current hyper frame number or incrementing or decrementing the current hyper frame number by one.

[0089] In some embodiments, the method can further include processing the plurality of data packets according to respective hyper frame numbers as evaluated.

[0090] In some embodiments, the method can further include evaluating the hyper frame number after deciphering only when the hyper frame number cannot be accurately identified prior to deciphering.

[0091] According to another aspect of the present disclosure, an apparatus for processing data packets in a transceiver can include at least one processor and at least one memory including computer program code. The at least one memory and the computer program code can be configured to, with the at least one processor, cause the transceiver at least to receive a plurality of data packets at a packet data convergence protocol layer. The at least one memory and the computer program code can also be configured to, with the at least one processor, cause the transceiver at least to determine whether a hyper frame number of each data packet of the plurality of data packets can be accurately identified prior to deciphering. The at least one memory and the computer program code can further be configured to, with the at least one processor, cause the transceiver at least to evaluate the hyper frame number before deciphering only when the hyper frame number can be accurately identified prior to deciphering.

[0092] In some embodiments, the determining is based on a sequence number of each data packet of the plurality of data packets.

[0093] In some embodiments, the determining can include assigning the sequence number to one of a plurality of zones and evaluating the hyper frame number based on the zone in which the sequence number is assigned.

[0094] In some embodiments, the determining can be based on comparing a sequence number to a window size.

[0095] In some embodiments, the evaluating the hyper frame number can include maintaining a current hyper frame number or incrementing or decrementing the current hyper frame number by one.

[0096] In some embodiments, the at least one memory and the computer program code can be further configured to, with the at least one processor, cause the transceiver at least to process the plurality of data packets according to respective hyper frame numbers as evaluated. [0097] In some embodiments, the at least one memory and the computer program code can be further configured to, with the at least one processor, cause the transceiver at least to evaluate the hyper frame number after deciphering only when the hyper frame number cannot be accurately identified prior to deciphering.

[0098] According to a further aspect of the present disclosure, a non-transitory computer- readable medium can be encoded with instructions that, when executed in a processor, perform a process for processing data packets in a transceiver. The process can include receiving a plurality of data packets at a packet data convergence protocol layer. The process can also include determining whether a hyper frame number of each data packet of the plurality of data packets can be accurately identified prior to deciphering. The process can further include evaluating the hyper frame number before deciphering only when the hyper frame number can be accurately identified prior to deciphering.

[0099] In some embodiments, the determining is based on a sequence number of each data packet of the plurality of data packets.

[0100] In some embodiments, the determining can include assigning the sequence number to one of a plurality of zones and evaluating the hyper frame number based on the zone in which the sequence number is assigned.

[0101] In some embodiments, the determining can be based on comparing a sequence number to a window size.

[0102] In some embodiments, the evaluating the hyper frame number can include maintaining a current hyper frame number or incrementing or decrementing the current hyper frame number by one.

[0103] In some embodiments, the process can further include processing the plurality of data packets according to respective hyper frame numbers as evaluated.

[0104] In some embodiments, the process can further include evaluating the hyper frame number after deciphering only when the hyper frame number cannot be accurately identified prior to deciphering.

[0105] The foregoing description of the specific embodiments will so reveal the general nature of the present disclosure that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present disclosure. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance. [0106] Embodiments of the present disclosure have been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed. [0107] The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present disclosure as contemplated by the inventor(s), and thus, are not intended to limit the present disclosure and the appended claims in any way.

[0108] Various functional blocks, modules, and steps are disclosed above. The particular arrangements provided are illustrative and without limitation. Accordingly, the functional blocks, modules, and steps may be re-ordered or combined in different ways than in the examples provided above. Likewise, certain embodiments include only a subset of the functional blocks, modules, and steps, and any such subset is permitted.

[0109] The breadth and scope of the present disclosure should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.