US20080226074A1 - Method and apparatus for ciphering packet units in wireless communications - Google Patents

Method and apparatus for ciphering packet units in wireless communications Download PDF

Info

Publication number
US20080226074A1
US20080226074A1 US12048120 US4812008A US2008226074A1 US 20080226074 A1 US20080226074 A1 US 20080226074A1 US 12048120 US12048120 US 12048120 US 4812008 A US4812008 A US 4812008A US 2008226074 A1 US2008226074 A1 US 2008226074A1
Authority
US
Grant status
Application
Patent type
Prior art keywords
rlc
pu
pdu
ciphering
sn
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Abandoned
Application number
US12048120
Inventor
Mohammed Sammour
Shankar Somasundaram
Peter S. Wang
Rajat P. Mukherjee
Stephen E. Terry
Jin Wang
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
InterDigital Technology Corp
Original Assignee
InterDigital Technology Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/08Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0816Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
    • H04L9/0819Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W12/00Security arrangements, e.g. access security or fraud detection; Authentication, e.g. verifying user identity or authorisation; Protecting privacy or anonymity
    • H04W12/04Key management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation, e.g. WAP [Wireless Application Protocol]
    • H04W80/02Data link layer protocols
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/24Key scheduling, i.e. generating round keys or sub-keys for block encryption
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W12/00Security arrangements, e.g. access security or fraud detection; Authentication, e.g. verifying user identity or authorisation; Protecting privacy or anonymity
    • H04W12/02Protecting privacy or anonymity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATIONS NETWORKS
    • H04W28/00Network traffic or resource management
    • H04W28/02Traffic management, e.g. flow control or congestion control
    • H04W28/06Optimizing the usage of the radio link, e.g. header compression, information sizing, discarding information

Abstract

A method and apparatus are disclosed relating to ciphering and de-ciphering of packet units in wireless devices during retransmission in wireless communications. The packet units are re-segmented with the ciphering done on the re-segmented packet unit or on a radio link control protocol data unit (RLC PDU) with or without segmentation. Alternatively, the re-segmentation is done on the radio link control service data unit (RLC SDU) with or without segmentation. Alternatively, the ciphering process and multiplexing of the RLC PDU is done in the medium access control (MAC) layer of a MAC PU before undergoing a hybrid automatic repeat request (HARQ) process for retransmission. Further, the ciphering process in the RLC is done on a packet data convergence protocol packet data unit (PDCP PDU).

Description

    CROSS REFERENCE TO RELATED APPLICATIONS
  • This application claims the benefit of U.S. provisional application No. 60/895,134 filed Mar. 15, 2007, which is incorporated by reference as if fully set forth.
  • FIELD OF INVENTION
  • This invention relates to wireless communication.
  • BACKGROUND
  • The third generation partnership project (3GPP) has lately initiated the Long Term Evolution (LTE) program to bring new technology, new network architecture, new configuration and new applications and services to the wireless cellular network in order to provide improved spectral efficiency and faster user experiences.
  • Universal Mobile Telecommunications System (UMTS) Ciphering Architecture
  • UMTS systems such as Release 6, the ciphering function is performed in either in the Radio Link Controller (RLC) sub-layer or in the Medium Access Control (MAC) sub-layer, according to the following rules:
      • If a radio bearer is using a non-transparent RLC mode (Acknowledged Mode (AM) or Unacknowledged Mode (UM)), ciphering is performed in the RLC sub-layer.
      • If a radio bearer is using the transparent RLC mode, ciphering is performed in the MAC sub-layer (dedicated MAC (MAC-d) entity).
  • For uplink traffic, ciphering is done in the Wireless Transmit/Receive Unit (WTRU) and deciphering in the Radio Network Controller (RNC), and for downlink traffic, ciphering is done in the RNC and deciphering in the WTRU.
  • The ciphering and integrity protection algorithms are described in 3GPP TS 33.102 V6.5.0 (2005-12). Of particular relevance are the COUNT-C (ciphering) and COUNT-I (integrity) input parameters, which are used by the ciphering and integrity protection algorithms respectively.
  • As shown in FIG. 1, a COUNT-C configuration, where the COUNT-C is utilized for performing ciphering on radio bearers using RLC TM 10 and COUNT-C is utilized for performing ciphering on radio bearer using RLC AM 30, or a RLC UM 20. For all transparent mode RLC radio bearers of the same core network (CN) domain, COUNT-C is the same, and COUNT-C is also the same for uplink and downlink.
  • The ciphering sequence number COUNT-C is 32 bits long. COUNT-C is composed of two parts: a “short” sequence number and a “long” sequence number. The “short” sequence number forms the least significant bits of COUNT-C while the “long” sequence number forms the most significant bits of COUNT-C, and is known as the Hyper Frame Number (HFN).
  • The update of COUNT-C depends on the transmission mode as described below:
      • For RLC TM on Dedicated Channel (DCH), the “short” sequence number is the 8-bit connection frame number (CFN) of COUNT C. It is independently maintained in the WTRU MAC-d entity and the Servicing RNC (SRNC) MAC-d entity. The “long” sequence number is the 24-bit MAC-d HFN, which is incremented at each CFN cycle.
      • For RLC UM mode, the “short” sequence number is the 7-bit RLC sequence number (RLC SN) and this is part of the RLC UM Protocol Data Unit (PDU) header. The “long” sequence number is the 25-bit RLC UM HFN which is incremented at each RLC SN cycle.
      • For RLC AM mode, the “short” sequence number is the 12-bit RLC sequence number (RLC SN) and this is part of the RLC AM PDU header. The “long” sequence number is the 20-bit RLC AM HFN which is incremented at each RLC SN cycle.
  • The hyperframe number HFN is initialized by means of the parameter START. The WTRU and the RNC then initialize the 20 most significant bits of the RLC AM HFN, RLC UM HFN and MAC-d HFN to START. The remaining bits of the RLC AM HFN, RLC UM HFN and MAC-d HFN are initialized to zero. The hyper frame number is not explicitly transmitted with the packet.
  • Similarly, COUNT-I is composed of two parts: a “short” sequence number and a “long” sequence number. The “short” sequence number forms the least significant bits of COUNT-I, while the “long” sequence number forms the most significant bits of COUNT-I. The “short” sequence number is the 4-bit Radio Resource Control (RRC) sequence number (RRC SN) that is available in each RRC PDU. The “long” sequence number is the 28-bit RRC hyper frame number (RRC HFN) which is incremented at each RRC SN cycle.
  • LTE Architecture
  • FIG. 2 shows known LTE Layer 2 architecture in which the ciphering is done in the Packet Data Convergence Protocol (PDCP) layer 210 according to the current LTE architecture. The PDCP layer is located in the WTRU for the uplink traffic case, and used to be located in the access gateway (aGW) for the downlink traffic case according to the prior LTE decision.
  • Recently the Radio Access Network (RAN) WG3 in 3GPP made a decision to move ciphering and PDCP functionalities from the access gateway (aGW) to the enhanced Node B (eNB). As a result of this decision several issues need to be addressed in the area of devising a ciphering architecture that is effective and efficient.
  • RLC
  • Some of the main services and functions of the RLC sub-layer include:
      • Transfer of upper layer PDUs supporting AM or UM;
      • TM data transfer;
      • Error Correction through automatic repeat request (ARQ) (Cyclic Redundancy Check (CRC) check provided by the physical layer, in other words no CRC needed at RLC level);
      • Segmentation according to the size of the Transport Block (TB): only if an RLC Service Data Unit (SDU) does not fit entirely into the TB then the RLC SDU is segmented into variable sized RLC PDUs, which do not include any padding;
      • Re-segmentation of PDUs that need to be retransmitted: if a retransmitted PDU does not fit entirely into the new TB used for retransmission then the RLC PDU is re-segmented;
      • The number of re-segmentation is not limited;
      • Concatenation of SDUs for the same radio bearer;
      • In-sequence delivery of upper layer PDUs except at Handover (HO) in the uplink;
      • Duplicate Detection;
  • FIG. 3 shows the RLC PDU structure where the PDU sequence number carried by the RLC header 310 is independent of the SDU sequence number (i.e. PDCP sequence number). The division lines in SDUn 320 and SDUn+3 330 indicate occurrence of segmentation. Because segmentation only occurs when needed and concatenation is done in sequence, the content of an RLC PDU can generally be described by the following relations:
      • {0; 1} last segment of SDUi+[0; n] complete SDUs+{0; 1} first segment of SDUi+n+1; or
      • 1 segment of SDUi.
  • FIG. 3 and FIG. 4 describe some of the RLC functions. The RLC layer receives RLC SDUs from the layer above it (i.e. PDCP); based on the size of the Transport Block (TB) to be sent in a Transmission Time Interval (TTI), the RLC either segments the SDU, leaves the SDU as is, or creates a concatenation of SDUs and segments 410, in a manner that maximizes the utilization of the TB. This results in an initial RLC PDU that gets transmitted. The initial RLC PDU 420 (or its constituent information) will also be kept in a retransmission (ReTx) buffer 430 until it is successfully acknowledged. In case of errors or lack of reception, the unacknowledged PDU may be retransmitted by ARQ either as is, or may undergo PDU re-segmentation 440 where the PDU is further segmented into sub-PDU's for retransmission 450. Hence the RLC retransmission unit is the RLC PDU or an RLC Sub-PDU depending on whether re-segmentation is performed or not.
  • In the RLC PDU re-segmentation scheme, there are two levels of identifications employed by the RLC:
  • 1) RLC PDU SN to identify the RLC PDU
  • 2) RLC Sub-PDU identifier, which could take the form of either:
      • a. SN, e.g. Sub-PDU SN, or:
      • b. Offset and Length, e.g. in Bytes, relative to the PDU.
  • In the RLC SDU re-segmentation scheme, there are two levels of identifications employed by the RLC:
  • 1) RLC SDU SN to identify the RLC SDU
  • 2) RLC Sub-SDU identifier, which could take the form of either:
      • a. SN, e.g. Segment SN or Sub-SDU SN, or:
      • b. Offset and Length, e.g. in Bytes, relative to the SDU.
  • PDU re-segmentation is described, but SDU re-segmentation is also possible. FIG. 5 illustrates an example implementation that performs SDU re-segmentation.
  • What is needed are different alternatives for efficient and/or low complexity user plane architectures designed to support ciphering operation in an efficient and/or low complexity manner; where the prior art does not provide alternatives of MAC and RLC ciphering.
  • In UMTS systems, there was only one level of RLC segmentation, and there was no RLC re-segmentation. LTE RLC re-segmentation introduces problems in regards to how the ciphering SN (C-COUNT) is to be constructed efficiently. This is further complicated by being dependent on the various numbering schemes that may be employed by RLC for other functions such as ARQ and reordering.
  • SUMMARY
  • A method and apparatus are disclosed for ciphering and de-ciphering of packet units in wireless devices during retransmission in wireless communications. Processing of a packet unit (PU) in a radio link control (RLC) layer for retransmission includes buffering the PU, re-segmenting of the PU in the buffer, performing a ciphering process on the PU or the re-segmented PU, and retransmitting the ciphered and re-segmented PU.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • A more detailed understanding of the invention may be had from the following description, given by way of example in conjunction with the accompanying drawings wherein:
  • FIG. 1 shows a ciphering sequence number COUNT-C configuration used by RLC.
  • FIG. 2 shows an LTE Layer 2 architecture in which the ciphering is done in the PDCP layer according to the known LTE architecture.
  • FIG. 3 shows an RLC PDU may contain a segment of an SDU, or a concatenation of SDUs and segments.
  • FIG. 4 shows some of the RLC functions, assuming re-segmentation is performed on RLC PDUs.
  • FIG. 5 illustrates some of the RLC functions, assuming re-segmentation is performed on RLC SDUs.
  • FIG. 6A shows ciphering performed on RLC PDUs but not on RLC Sub-PDUs if retransmission occurs.
  • FIGS. 6B-6F show variations of Count-C configurations according to a first embodiment.
  • FIG. 7 shows ciphering performed on RLC PDUs and also on RLC Sub-PDUs if retransmission occurs according to a second embodiment.
  • FIGS. 8A-8H show variations of Count-C configurations according to a second embodiment.
  • FIG. 9 shows ciphering performed on RLC SDUs according to a third embodiment.
  • FIGS. 10A-10C show variations of Count-C configurations according to a third embodiment.
  • FIG. 11 shows ciphering performed in the MAC layer on MAC SDUs after multiplexing.
  • FIGS. 12A-12B show variations of Count-C configurations according to a fourth embodiment.
  • FIG. 13 shows ciphering performed in the MAC layer on MAC SDUs before multiplexing.
  • FIG. 14 shows a wireless communications system.
  • FIG. 15 is a functional block diagram of a WTRU and an enhanced Node B (eNB).
  • FIG. 16 shows a RXN procedure from the ciphering performed on RLC PDUs but not on RLC Sub-PDUs.
  • FIG. 17 shows a RXN procedure from the ciphering performed on RLC PDUs and also on RLC Sub-PDUs.
  • FIG. 18 shows a RXN procedure from the ciphering performed on RLC SDUs.
  • FIG. 19 shows a RXN procedure from the ciphering performed in the MAC layer on MAC SDUs after multiplexing.
  • FIG. 20 shows a RXN procedure from the ciphering performed in the MAC layer on MAC SDUs before multiplexing.
  • DETAILED DESCRIPTION
  • When referred to hereafter, the terminology “wireless transmit/receive unit (WTRU)” includes but is not limited to a user equipment (UE), a mobile station, a fixed or mobile subscriber unit, a pager, a cellular telephone, a personal digital assistant (PDA), a computer, or any other type of user device capable of operating in a wireless environment. When referred to hereafter, the terminology “base station” includes but is not limited to a Node-B, a site controller, an access point (AP), or any other type of interfacing device capable of operating in a wireless environment.
  • FIG. 14 shows a wireless communication network. The wireless communication network in FIG. 14 includes a plurality of WTRUs 1410 and an eNB 1420. As shown in FIG. 14, the WTRUs 1410 are in communication with the eNB 1420. Although three WTRUs 1410 and one eNB 1420 are shown in FIG. 14, it should be noted that any combination of wireless and wired devices may be included in the wireless communication network.
  • FIG. 15 is a functional block diagram of a WTRU 1410 and the eNB 1420 of the wireless communication network of FIG. 14. As shown in FIG. 14, the WTRU 1410 is in communication with the enhance Node B (eNB) 1420 and both are configured to perform a method of re-segmentation of the stored PU in a buffer in their respective processors 1515 and 1525 for retransmission.
  • In addition to the components that may be found in a typical WTRU, the WTRU 1410 includes the processor with a buffer 1515, a receiver 1517, a transmitter 1516, and an antenna 1518. The processor 1515 is be configured to perform de-ciphering of re-segmented Packet Unit (PU) from downlink wireless data from the eNB 1420 and ciphering on the re-segmentation of the PUs of uplink wireless data of the WTRU 1410. The receiver 1517 and the transmitter 1516 are in communication with the processor 1515. The antenna 1518 is in communication with both the receiver 1517 and the transmitter 1516 to facilitate the transmission and reception of wireless data.
  • In addition to the components that may be found in a typical eNB 1420, the eNB 1420 includes the processor with a buffer 1525, a receiver 1526, a transmitter 1527, and an antenna 1528. The processor 1525 is configured to perform de-ciphering of the received re-segmented PUs from uplink wireless data from WTRU 1410, and ciphering of the re-segmentation of PUs of downlink wireless data to WTRU 1410. The receiver 1526 and the transmitter 1527 are in communication with the processor 1525. The antenna 1528 is in communication with both the receiver 1526 and the transmitter 1527 to facilitate the transmission and reception of wireless data.
  • Ciphering at the RLC Layer
  • Some or all of the embodiments described may be applied to any mode of RLC operation (e.g. AM, UM or TM), although the examples focus on RLC AM operation which utilizes ARQ retransmission.
  • Ciphering in RLC: Alternative 1
  • The transmitting node that is performing the ciphering operation (i.e. the WTRU for uplink traffic, and the eNB for downlink traffic) preferably performs ciphering on the initial PDUs created by the RLC and will not perform ciphering again on the Sub-PDUs that are retransmitted by the RLC, as shown in FIG. 6A.
  • According to this architecture, the transmitting node (TXN) (i.e. the WTRU in case of uplink traffic direction, and the eNB in case of downlink traffic direction) will perform the following procedure as shown in FIGS. 6B-6F:
      • First, the TXN may perform segmentation and concatenation 601 on one or more of the RLC SDU(s) and create an initial RLC PDU
      • The TXN will cipher the payload of the initial RLC PDU 602 (initial here refers to the first level of segmentation/concatenation operation, as opposed to further levels)
      • The TXN will store a copy of the ciphered initial RLC PDU in the ReTx buffer 603, to support future retransmission if needed
      • The TXN will transmit the ciphered initial RLC PDU
      • In case ARQ retransmission is required:
      • The TXN will use the ciphered initial RLC PDU stored in the ReTx buffer
      • The TXN may re-segment the stored PDU 604 and create one or more Sub-PDUs 605.
        The retransmitted RLC PDUs or Sub-PDUs are not re-ciphered.
  • In FIG. 16, the receiving node (RXN) (i.e. the WTRU in case of downlink traffic direction, and the eNB in case of uplink traffic direction) will perform the following procedure:
      • First, the RXN reassemble an initial RLC PDU from multiple Sub-PDUs, or from a single PDU in case no re-segmentation was done 1610
      • The RXN will de-cipher the payload of the initial RLC PDU 1620
      • The RXN will reassemble the RLC SDU from multiple PDUs in case segmentation was done, or from a single PDU in case no segmentation was done; The RXN will de-concatenate the RLC SDUs from the PDU in case concatenation was done 1630.
  • Although the operations described above assume PDU re-segmentation is performed, the schemes described above apply as well when SDU re-segmentation is employed instead.
  • In this RLC ciphering Alternative 1, the ciphering sequence number such as COUNT-C will preferably make use of the sequence number(s) or packet identifiers that are provided by the RLC. Depending on how the RLC provides sequence numbering and packet identification, different variants can exist:
  • Variant 1: RLC PDU SN
  • In FIG. 6B, if the RLC performs numbering on an RLC PDU level (i.e. PDU SN), the COUNT-C will be constructed from the RLC PDU SN 611 and a RLC HFN 612.
  • The RLC HFN is incremented at each RLC PDU SN cycle.
  • Variant 2: RLC SDU SN+RLC Segment Offset/Length
  • In FIG. 6C, if the RLC performs numbering on an RLC SDU level (i.e. SDU SN), and identifies segments (i.e. Sub-SDUs) using offset and length (e.g. in bytes), the COUNT-C will be constructed from the RLC SDU SN 621, 629, 609, and either all or parts (e.g. LSB's) of the RLC segment offset 620, 622, 624 or/and length fields 623, 625, and an RLC HFN 626, 627, 628.
  • The RLC HFN is incremented at each RLC SDU SN cycle, since the RLC Segment Offset or Length fields may have gaps (i.e. values that will never be reached or assigned); i.e. even if the Segment offset or length fields does not roll over (since it may not reach its maximum), the RLC HFN will be incremented whenever the RLC SDU SN rolls over (upon reaching its maximum).
  • Variant 3: RLC SDU SN+RLC Segment Number
  • In FIG. 6D, if the RLC performs numbering on an RLC SDU level (i.e. SDU SN), and identifies segments (i.e. Sub-SDUs) using segment sequence numbers, the COUNT-C will be constructed from the RLC SDU SN 631, and the RLC segment number 632, and a RLC HFN 633.
  • The RLC HFN is incremented at each RLC SDU SN cycle, since the RLC Segment SN field may have gaps (i.e. values that will never be reached or assigned); that is even if the RLC Segment SN does not roll over (since it may not reach its maximum), the RLC HFN will be incremented whenever the RLC SDU SN rolls over (upon reaching its maximum).
  • Variant 4: RLC SDU SN+RLC Derived SN
  • In FIG. 6E, an alternative variation would be to not directly use the RLC numbers utilized for RLC reassembly and reordering operations, but rather create another SN to be dedicated for ciphering purposes, whereby the COUNT-C will be constructed from the new RLC derived SN 641, the RLC SDU SN 642, and a RLC HFN 643. The new RLC derived SN may be a function of existing RLC numbers/identifiers (e.g. offset/length), or may be independently assigned.
  • The RLC HFN is incremented at each RLC SDU SN cycle; alternatively, the HFN is incremented at each RLC SDU SN and RLC Derived SN cycle.
  • Variant 5: New RLC Ciphering SN
  • In FIG. 6F, an alternative variation would be to not directly use the RLC numbers utilized for RLC reassembly and reordering operations, but rather create another SN to be dedicated for ciphering purposes, whereby the COUNT-C will be constructed from the new ciphering SN 651, and a RLC HFN 652. The new RLC ciphering SN may be a function of existing RLC numbers/identifiers, or may be independently assigned.
  • The RLC HFN is incremented at each RLC Ciphering SN cycle.
  • It should be noted that FIGS. 6B-6F are not drawn to scale and are not aimed to be indicative of the relative size or actual number of bits that constitute each field. Also, the total number of bits in COUNT-C may remain as 32 bits, or may be changed, e.g. increased to a larger number of bits (e.g. 64 bits) or any other number. For the integrity protection algorithm/operation, COUNT-I may be constructed utilizing similar schemes/principles to the above in certain cases.
  • The variants 1-5 for this embodiment:
      • Do not require re-ciphering of re-transmitted PDUs or Sub-PDUs
      • Ciphering sequence number (i.e. COUNT-C) may reuse/make use of existing RLC SN and/or identifiers as input(s), hence resulting in reduced overhead.
  • Ciphering in RLC: Alternative 2
  • In FIG. 7, the transmitting node that is performing the ciphering operation (i.e. the UE for uplink traffic, and the eNB for downlink traffic) will perform ciphering on the initial PDUs created by the RLC and will also perform ciphering on the Sub-PDUs or PDUs that are retransmitted by the RLC.
  • According to the architecture, the transmitting node (TXN) (i.e. the WTRU in case of uplink traffic direction, and the eNB in case of downlink traffic direction) will perform the following procedure:
      • First, the TXN may perform segmentation and concatenation 710 on one or more of the RLC SDU(s) and create an initial RLC PDU
      • The TXN will store a copy of the non-ciphered initial RLC PDU in the ReTx buffer 720, to support future retransmission if needed
      • The TXN will cipher the payload of the initial RLC PDU (“initial” here refers to the first level of segmentation/concatenation operation, as opposed to further levels)
      • The TXN will transmit the ciphered initial RLC PDU.
      • In case ARQ retransmission is required:
        • The TXN will use the non-ciphered initial RLC PDU stored in the ReTx buffer 720
        • The TXN may re-segment the stored PDU 730 and create one or more Sub-PDUs 740
        • The TXN will cipher the payload of the created PDUs or Sub-PDUs 750.
          The retransmitted RLC PDUs or Sub-PDUs will be ciphered.
  • As shown in FIG. 17, according to this architecture, the receiving node (RXN) (i.e. the UE in case of downlink traffic direction, and the eNB in case of uplink traffic direction) will perform the following procedure:
      • First, the RXN will decipher the payload of the initial RLC PDUs or Sub-PDUs it receives 1710
      • The RXN reassemble an initial RLC PDU from multiple Sub-PDUs or from a single PDU in case no re-segmentation was done 1720
      • The RXN will reassemble the RLC SDU from multiple PDUs in case segmentation was done, or from a single PDU in case no segmentation was done; The RXN will de-concatenate the RLC SDUs from the PDU in case concatenation was done 1730.
  • Although the operations above assume PDU re-segmentation is performed, the schemes described above can apply when SDU re-segmentation is employed instead.
  • In this RLC ciphering Alternative 2, the ciphering sequence number such as COUNT-C will preferably make use of the sequence number(s) or packet identifiers that are provided by the RLC. Depending on how the RLC provides sequence numbering and packet identification, different variants can exist:
  • Variant 1: RLC PDU SN+RLC Sub-PDU Offset/Length
  • In FIG. 8A, if the RLC performs numbering on an RLC PDU level (i.e. PDU SN), and identifies sub-segments (i.e. Sub-PDUs) using offset and length (e.g. in bytes), the COUNT-C will be constructed from the RLC PDU SN 770, 780, 811, and either all or parts (e.g. LSB's) of the RLC Sub-PDU offset 810 812, 814 or/and length fields 813, 815, and a RLC HFN 816, 817, 818. For an Initial PDU (as opposed to a Sub-PDU), the offset and/or length fields may either be set to zeros in the COUNT-C, or automatically padded to zeros by the ciphering engine.
  • The RLC HFN is incremented at each RLC PDU SN cycle, since the RLC Sub-PDU Offset or Length fields may have gaps (i.e. values that will never be reached or assigned); i.e. even if the Sub-PDU offset or length fields does not roll over (since it may not reach its maximum), the RLC HFN will be incremented whenever the RLC PDU SN rolls over (upon reaching its maximum).
  • Variant 2: RLC PDU SN+Sub-PDU SN
  • In FIG. 8B, if the RLC performs numbering on an RLC PDU level (i.e. PDU SN), and identifies sub-segments (i.e. Sub-PDUs) using sequence numbers, the COUNT-C will be constructed from the RLC PDU SN 821, and the RLC Sub-PDU SN 822, and a RLC HFN 823. For an Initial PDU (as opposed to a Sub-PDU), the RLC Sub-PDU SN field may either be set to zeros in the COUNT-C, or automatically padded to zeros by the ciphering engine.
  • The RLC HFN is incremented at each RLC PDU SN cycle, since the RLC Sub-PDU SN field may have gaps (i.e. values that will never be reached or assigned); that is even if the RLC Sub-PDU SN does not roll over (since it may not reach its maximum), the RLC HFN will be incremented whenever the RLC PDU SN rolls over (upon reaching its maximum).
  • Variant 3: RLC PDU SN+Derived SN
  • In FIG. 8C, an alternative variation would be to not directly use the RLC numbers utilized for RLC reassembly and reordering operations, but rather create another SN to be dedicated for ciphering purposes, whereby the COUNT-C will be constructed from the new RLC derived SN 831, the RLC PDU SN 832, and a RLC HFN 833. The new RLC derived SN may be a function of existing RLC numbers/identifiers (e.g. offset/length), or may be independently assigned. For an Initial PDU (as opposed to a Sub-PDU), the RLC derived SN field may either be set to zeros in the COUNT-C, or automatically padded to zeros by the ciphering engine.
  • The RLC HFN is incremented at each RLC PDU SN cycle; alternatively, the RLC HFN is incremented at each RLC PDU SN and RLC Derived SN cycle.
  • Variant 4: RLC SDU SN+RLC Segment Offset/Length
  • In FIG. 8D, if the RLC performs numbering on an RLC SDU level (i.e. SDU SN), and identifies segments (i.e. Sub-SDUs) using offset and length (e.g. in bytes), the COUNT-C will be constructed from the RLC SDU SN 846, 847, 848, and either all or parts (e.g. LSB's) of the RLC segment offset(s) 841, 843, 845 or/and RLC length fields 842, 844, and a RLC HFN 849, 857, 858. The RLC HFN is incremented at each RLC SDU SN cycle, since the RLC Segment Offset or Length fields may have gaps (i.e. values that will never be reached or assigned); i.e. even if the Segment offset or length fields does not roll over (since it may not reach its maximum), the RLC HFN will be incremented whenever the RLC SDU SN rolls over (upon reaching its maximum).
  • Variant 5: RLC SDU SN+Segment Number
  • In FIG. 8E, if the RLC performs numbering on an RLC SDU level (i.e. SDU SN), and identifies segments (i.e. Sub-SDUs) using segment sequence numbers, the COUNT-C will be constructed from the RLC SDU SN 851, and the RLC segment number 852, and a RLC HFN 853.
  • The RLC HFN is incremented at each RLC SDU SN cycle, since the RLC Segment SN field may have gaps (i.e. values that will never be reached or assigned); that is even if the Segment SN does not roll over (since it may not reach its maximum), the RLC HFN will be incremented whenever the RLC SDU SN rolls over (upon reaching its maximum).
  • Variant 6: RLC SDU SN+RLC Derived SN
  • In FIG. 8F, an alternative variation would be to not directly use the RLC numbers utilized for RLC reassembly and reordering operations, but rather create another SN to be dedicated for ciphering purposes, whereby the COUNT-C will be constructed from the new RLC derived SN 861, the RLC SDU SN 862, and a RLC HFN 863. The new RLC derived SN may be a function of existing RLC numbers/identifiers (e.g. offset/length), or may be independently assigned.
  • The RLC HFN is incremented at each RLC SDU SN cycle; alternatively, the HFN is incremented at each RLC SDU SN and RLC Derived SN cycle.
  • Variant 7: New Ciphering SN
  • In FIG. 8G, an alternative variation would be to not directly use the RLC numbers utilized for RLC reassembly and reordering operations, but rather create another SN to be dedicated for ciphering purposes, whereby the COUNT-C will be constructed from the new RLC ciphering SN 871, and a RLC HFN 872. The new RLC ciphering SN may be a function of existing RLC numbers/identifiers, or may be independently assigned.
  • The RLC HFN is incremented at each RLC Ciphering SN cycle.
  • Variant 8: New RLC Transmission SN
  • In FIG. 8H, an alternative variation would be to not directly use the RLC numbers utilized for RLC reassembly and reordering operations, but rather create another RLC Transmission SN to be assigned across all packets transmitted from the RLC, or across only those packets belonging to one logical channel (i.e. per logical channel SN) or to certain RLC modes (e.g. per-AM mode SN), whereby the COUNT-C will be constructed from the new RLC Transmission SN 881, and a RLC HFN 882.
  • The RLC HFN is incremented at each RLC Transmission SN cycle.
  • In FIGS. 8A-8H, the fields are not drawn to scale and are not aimed to be indicative of the relative size or actual number of bits that constitute each field. The total number of bits in COUNT-C may remain as 32 bits, or may be changed, e.g. increased to a larger number of bits (e.g. 64 bits) or any other number. For the integrity protection algorithm/operation, COUNT-I may be constructed utilizing similar schemes/principles to the above in certain cases.
  • In this embodiment:
      • Ciphering location is at the low portion of the RLC, hence it is closer or more amenable to make use of hardware implementations
      • Ciphering sequence number (i.e. COUNT-C) may reuse/make use of existing RLC SN and/or identifiers as input(s), hence resulting in reduced overhead
      • The receiver can optimize reassembly implementations since the deciphering operation does not separate the two levels of reassembly operations.
  • Ciphering in RLC: Alternative 3
  • As shown in FIG. 9 in this embodiment, the transmitting node that is performing the ciphering operation (i.e. the UE for uplink traffic, and the eNB for downlink traffic) will perform ciphering on the RLC SDUs received from the PDCP layer above the RLC. There are two variations for doing ciphering in this case:
      • Ciphering is done on the whole the PDCP PDU (i.e. RLC SDU payload)
      • Ciphering is done only on the PDCP PDU payload (i.e. the PDCP SDU), and exclude the PDCP header.
  • According to the architecture, the transmitting node (TXN) (i.e. the UE in case of uplink traffic direction, and the eNB in case of downlink traffic direction) will perform the following procedure:
      • First, the TXN will cipher the payload of the RLC SDU (in one variant) or will cipher the whole RLC SDU (in another variant) 901
      • The TXN may perform segmentation and concatenation on one or more of the RLC SDU(s) and create an initial RLC PDU 902
      • The TXN will store a copy of the initial RLC PDU in the ReTx buffer 903, to support future retransmission if needed
      • The TXN will transmit the initial RLC PDU.
      • In case ARQ retransmission is required:
        • The TXN will use the initial RLC PDU stored in the ReTx buffer 904
        • The TXN may re-segment the stored PDU and create one or more Sub-PDUs 905.
          The retransmitted RLC PDUs or Sub-PDUs 906 are not re-ciphered, since ciphering is only done on the RLC SDUs.
  • According to FIG. 18, the receiving node (RXN) (i.e. the UE in case of downlink traffic direction, and the eNB in case of uplink traffic direction) will perform the following procedure:
      • First, the RXN reassembles an initial RLC PDU from multiple Sub-PDUs, or from a single PDU in case no re-segmentation was done 1810
        • The RXN reassembles the RLC SDU from multiple PDUs in case segmentation was done, or from a single PDU in case no segmentation was done. The RXN de-concatenates the RLC SDUs from the PDU in case concatenation was done 1820
        • The RXN deciphers the payload of the RLC SDU (in one variant) or deciphers the whole RLC SDU (in another variant) 1830.
  • Although it is assumed that PDU re-segmentation is performed in the operations above, the schemes described above can still apply when SDU re-segmentation is employed instead.
  • In this third embodiment of RLC ciphering Alternative 3, the ciphering sequence number such as COUNT-C preferably makes use of the sequence number(s) or packet identifiers that are provided by the RLC. Depending on how the RLC provides sequence numbering and packet identification, and depending on if the PDCP layer above RLC provides its own sequence numbering, different variants can exist:
  • Variant 1: PDCP PDU SN
  • In FIG. 10A, if the PDCP layer performs sequence numbering on a PDCP PDU level (i.e. PDCP PDU SN), the COUNT-C will be constructed from the PDCP PDU SN 1011 and a RLC HFN 1012.
  • The RLC HFN is incremented at each PDCP PDU SN cycle.
  • Variant 2: RLC SDU SN
  • In FIG. 10B, if the RLC performs numbering on an RLC SDU level (i.e. RLC SDU SN), the COUNT-C will be constructed from the RLC SDU SN 1021 and a RLC HFN 1022.
  • The RLC HFN is incremented at each RLC SDU SN cycle.
  • Variant 3: New RLC Ciphering SN
  • In FIG. 10C, an alternative variation would be to not directly use the RLC numbers utilized for RLC reassembly or reordering operations, but rather create another SN to be dedicated for ciphering purposes, whereby the COUNT-C will be constructed from the new RLC ciphering SN 1031, and a RLC HFN 1032. The new RLC ciphering SN may be a function of existing RLC numbers/identifiers, or may be independently assigned.
  • The RLC HFN is incremented at each RLC Ciphering SN cycle.
  • In this embodiment:
      • Re-ciphering of re-transmitted packets is not required;
      • Ciphering sequence number (i.e. COUNT-C) may reuse/make use of existing PDCP or RLC SN and/or identifiers as input(s), hence resulting in reduced overhead.
      • The receiver can optimize reassembly implementations since the deciphering operation does not separate the two levels of reassembly operations.
  • Ciphering at the MAC Layer
  • Ciphering for RLC TM traffic is performed in the MAC layer utilizing an 8-bit connection frame number CFN to construct COUNT-C. The CFN is derived from the System Frame Number (SFN). Such reliance on SFN will not be suitable for LTE ciphering purposes however, since LTE systems envision that all traffic types will make use of Hybrid ARQ (HARQ), which can change the order of packet reception.
  • Below is described how MAC ciphering can be achieved in LTE for any type/mode of traffic (e.g. AM, UM, TM), or for all modes of traffic.
  • Ciphering in MAC: Alternative 1
  • In FIG. 11, the transmitting node that is performing the ciphering operation 1101 (i.e. the UE for uplink traffic, and the eNB for downlink traffic) performs ciphering on the MAC “multiplexed packet” 1102 that results from the potential multiplexing of one or more MAC SDUs. There are two variations for ciphering in this case:
      • Ciphering is done on the whole the MAC “multiplexed packet”, which is our preferred embodiment
      • Ciphering is done only on the payload of the MAC “multiplexed packet”, and hence the “multiplexing” information/header will not be ciphered.
  • According, the transmitting node (TXN) (i.e. the UE in case of uplink traffic direction, and the eNB in case of downlink traffic direction) performs the following procedure as shown in FIG. 11:
      • First, the TXN may perform multiplexing (concatenation) of several MAC SDUs, and create a MAC “multiplexed packet” 1102.
      • The TXN ciphers 1101 the payload of the MAC “multiplexed packet” (in one variant) or ciphers the whole MAC “multiplexed packet” (in another preferred variant) and sends the resulting packet to a HARQ process 1103.
      • The TXN HARQ process transmits the packet.
  • In FIG. 19, the receiving node (RXN) (i.e. the WTRU in case of downlink traffic direction, and the eNB in case of uplink traffic direction) performs the following procedure:
      • The RXN HARQ process will receive the packet 1910
      • The RXN will decipher the payload of the MAC “multiplexed packet” (in one variant) or will decipher the whole MAC “multiplexed packet” (in another preferred variant) 1920
      • The RXN will de-multiplex (de-concatenate) the MAC SDUs from the received packet 1930.
  • In this MAC ciphering alternative, the ciphering sequence number such as COUNT-C is constructed using new MAC sequence numbers that are introduced in the LTE MAC layer to facilitate ciphering operations, since the SFN/CFN method will not work for LTE given that HARQ will be used for all traffic types (except possibly for initial access messages).
  • The new sequence number could be a MAC Ciphering SN (to be used solely for the purpose of ciphering operations), or could be a MAC Transmission SN (introduced for the purpose of ciphering operations, but possibly utilized for other purposes such as introducing a MAC-level reordering function in LTE). Such new sequence number (MAC Ciphering SN or MAC Transmission SN) may be utilized across all logical channels of the MAC, or alternatively, each logical channel can utilize its own sequence number, or alternatively, a group of logical channel(s) can utilize/share their own sequence number.
  • In case it is decided that certain traffic types will forgo HARQ retransmissions (e.g. by setting max number of HARQ retransmissions to 0 for example), then an optional provision may be made whereby for such services, the SFN/CFN can be used as input for COUNT-C in this case, instead of the new MAC sequence number.
  • Alternatively, in other variants for MAC level ciphering, the MAC may utilize some of the sequence numbering and packet identification provided by the RLC.
  • The following describes the different variants:
  • Variant 1: MAC Ciphering SN
  • In FIG. 12A, the MAC provides/assigns an SN to be dedicated for ciphering purposes, whereby the COUNT-C is constructed from such new MAC Ciphering SN 1211, and a MAC HFN 1212. The MAC Ciphering SN may be utilized across all MAC logical channels, or alternatively each one or each group of logical channels may have/utilize its/their own MAC Ciphering SN.
  • In this alternative, the MAC Ciphering SN is incremented every time a MAC “multiplexed packet” is sent to a HARQ process.
  • The MAC HFN is incremented at each MAC Ciphering SN cycle.
  • Variant 2: MAC Transmission SN
  • In FIG. 12B, the MAC provides/assigns an SN that is primarily introduced to be utilized for ciphering purposes and possibly utilized for other functions such as enabling MAC level packet re-ordering, whereby the COUNT-C will be constructed from such new MAC Transmission SN 1221, and a MAC HFN 1222. The MAC Transmission SN may be utilized across all MAC logical channels, or alternatively each one or each group of logical channels may have/utilize its/their own MAC Ciphering SN.
  • In this alternative, the MAC Transmission SN is incremented every time a MAC “multiplexed packet” is sent to a HARQ process.
  • The MAC HFN is incremented at each MAC Transmission SN cycle.
  • In this embodiment:
      • Ciphering location is in the MAC, hence it is closer or more amenable to make use of hardware implementations.
  • Ciphering in MAC: Alternative 2
  • In FIG. 13, the transmitting node that is performing the ciphering operation (i.e. the UE for uplink traffic, and the eNB for downlink traffic) performs ciphering on the RLC PDUs received from the RLC layer above the MAC. There are two variations for doing ciphering in this case:
      • Ciphering is done on the whole RLC PDU (i.e. MAC SDU payload), which is our preferred embodiment
      • Ciphering is done only on the RLC PDU payload (i.e. the RLC SDU), and hence the RLC header will not be ciphered.
  • According to this architecture, the transmitting node (TXN) (i.e. the UE in case of uplink traffic direction, and the eNB in case of downlink traffic direction) perform the following procedure:
      • First, the TXN will cipher 1301 the payload of the MAC SDU (in one variant) or will cipher the whole MAC SDU (in another preferred variant).
      • The TXN may perform multiplexing 1302 (concatenation) of several ciphered MAC SDUs, and send the resulting MAC “multiplexed packet” to a HARQ process.
      • The TXN HARQ process 1303 will transmit the packet.
  • In FIG. 20, the receiving node (RXN) (i.e. the UE in case of downlink traffic direction, and the eNB in case of uplink traffic direction) will perform the following procedure:
      • The RXN HARQ process will receive the packet 2010
      • The RXN will de-multiplex (de-concatenate) the MAC SDUs from the received MAC “multiplexed packet” 2020
      • For each MAC SDU, the RXN will decipher the payload of the MAC SDU (in one variant) or will decipher the whole MAC SDU (in another preferred variant) 2030.
  • Variant 1: MAC Ciphering SN
  • Similar to the Variant 1 MAC ciphering embodiment described above, except that in this alternative, the MAC Ciphering SN is incremented every time an RLC PDU is received.
  • Variant 2: MAC Transmission SN
  • Similar to the Variant 1 MAC ciphering embodiment described above, except that in this alternative, the MAC Transmission SN is incremented every time an RLC PDU is received.
  • Variant 3: Reusing RLC Numbering/Identification Information
  • In such variants, the MAC may reuse the RLC numbering/identification information instead of introducing MAC-level sequence numbers as described above for the RLC ciphering variants.
  • In this embodiment:
      • Ciphering location is in the MAC, hence it is closer or more amenable to make use of hardware implementations.
  • Flexible/Negotiable Sizes of the SN's Used for Ciphering
  • In order to avoid ambiguity due to insufficient SN sizes and SN roll-over problems, the TXN and RXN may negotiate the size of the SN field to be utilized to construct COUNT-C, depending on any traffic characteristics (e.g. data rate, QoS requirements, etc. . . . ), or any other criteria. For example, for certain ‘slow’ AM traffic flows, the TXN and RXN could negotiate a smaller RLC PDU SN size when compared to a ‘fast’ AM traffic flow.
  • Primitive to Dynamically Pass the “Length” Field Each Time a New Packet is Submitted into the Ciphering Engine
  • In UMTS systems, the packet “Length” input was semi-static for an RLC link since the RLC PDUs had a fixed size that was configurable. In LTE systems, with dynamically changing RLC PDU sizes due to adaptive segmentation according to the TB size every TTI, the “Length” indication has to be dynamically passed along with every PDU. Hence, we propose to add a new primitive between the layer that performs the ciphering (e.g. RLC, MAC or PDCP) and the ciphering engine, that will communicate the length of each packet supplied to the ciphering engine. Similarly, on the receiving side, we propose to add a similar primitive for the purpose of the deciphering engine.
  • Primitive to Pass the SN Information Between PDCP and RLC
  • In some of the variants proposed in previous sections, we propose that the RLC may reuse the PDCP SN as input into the RLC-located ciphering engine. Hence, we propose to add a new primitive between the PDCP and the RLC layers to separately communicate the PDCP SN for each of the packets the PDCP supplies to the RLC. Similarly, on the receiving side, we propose to add a similar primitive.
  • Primitive to Pass the SN Information Between RLC and MAC
  • In some of the variants proposed in previous sections, we propose that the MAC may reuse one or more of the various RLC SN's as input into the MAC-located ciphering engine. Hence, we propose to add a new primitive between the RLC and the MAC layers to separately communicate the RLC SN for each of the packets the RLC supplies to the MAC. Similarly, on the receiving side, we propose to add a similar primitive.
  • For the above described embodiments, the COUNT-C and its inputs (e.g. HFN, Sequence Numbers, segment length or segment offset, etc. . . . ) are not supposed to be ciphered when they are used as inputs to the COUNT-C, since they will be used/needed as inputs for the deciphering operation. Typically, COUNT-C will have a fixed length, while the HFN component of the COUNT-C will be shrunk (reduced in size) whenever either more inputs or longer inputs are taken in constructing the COUNT-C.
  • Although the features and elements of the present invention are described in the preferred embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the preferred embodiments or in various combinations with or without other features and elements of the present invention. The methods or flow charts provided in the present invention may be implemented in a computer program, software, or firmware tangibly embodied in a computer-readable storage medium for execution by a general purpose computer or a processor. Examples of computer-readable storage mediums include a read only memory (ROM), a random access memory (RAM), a register, cache memory, semiconductor memory devices, magnetic media such as internal hard disks and removable disks, magneto-optical media, and optical media such as CD-ROM disks, and digital versatile disks (DVDs).
  • Suitable processors include, by way of example, a general purpose processor, a special purpose processor, a conventional processor, a digital signal processor (DSP), a plurality of microprocessors, one or more microprocessors in association with a DSP core, a controller, a microcontroller, Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) circuits, any other type of integrated circuit (IC), and/or a state machine.
  • A processor in association with software may be used to implement a radio frequency transceiver for use in a wireless transmit receive unit (WTRU), user equipment (UE), terminal, base station, radio network controller (RNC), or any host computer. The WTRU may be used in conjunction with modules, implemented in hardware and/or software, such as a camera, a video camera module, a videophone, a speakerphone, a vibration device, a speaker, a microphone, a television transceiver, a hands free headset, a keyboard, a Bluetooth® module, a frequency modulated (FM) radio unit, a liquid crystal display (LCD) display unit, an organic light-emitting diode (OLED) display unit, a digital music player, a media player, a video game player module, an Internet browser, and/or any wireless local area network (WLAN) module.

Claims (75)

  1. 1. A method to process a packet unit (PU) in a radio link control (RLC) layer for transmission, the method comprising:
    buffering the PU;
    re-segmenting of the PU in the buffer;
    performing a ciphering process on the PU or the re-segmented PU; and
    transmitting the ciphered and re-segmented PU.
  2. 2. The method of claim 1 wherein the ciphering process is an exclusive or (XOR) operation of the PU with a ciphering mask produced by the ciphering process.
  3. 3. The method of claim 2 wherein the ciphering process utilizes a first COUNT-C parameter.
  4. 4. The method of claim 3 wherein the first COUNT-C parameter comprises a RLC hyper frame number (HFN) and a RLC sequence number (SN).
  5. 5. The method of claim 4 wherein the PU comprises at least one service data unit (SDU).
  6. 6. The method of claim 5 wherein the re-segmenting of the PU comprises segmenting into at least one sub-SDU.
  7. 7. The method of claim 6 wherein segments of the sub-SDU utilizes a second COUNT-C parameter for ciphering the segments of the sub-SDU.
  8. 8. The method of claim 7 wherein the second COUNT-C parameter comprises:
    a RLC HFN;
    a RLC SN for the SDU;
    a segment offset; and
    a length of the sub-SDU.
  9. 9. The method of claim 8 wherein the segment offset is a location of a first byte position of the sub-SDU from a predetermined location in the re-segmented PU.
  10. 10. The method of claim 8 wherein the length of the sub-SDU comprises the total number of bytes of the sub-SDU.
  11. 11. The method of claim 4 wherein the PU comprises at least one protocol data unit (PDU).
  12. 12. The method of claim 11 wherein the re-segmenting of the PU comprises segmenting into at least one sub-PDU.
  13. 13. The method of claim 12 wherein the segments of the sub-PDU utilizes a second COUNT-C parameter for ciphering the segments of the sub-PDU.
  14. 14. The method of claim 13 wherein the second COUNT-C parameter comprises:
    a RLC HFN;
    a RLC SN for the PDU;
    a segment offset; and
    a length of the sub-PDU.
  15. 15. The method of claim 14 wherein the segment offset is a location of a first byte position of the sub-PDU from a predetermined location in the re-segmented PU.
  16. 16. The method of claim 14 wherein the length of the sub-PDU comprises the total number of bytes of the sub-PDU.
  17. 17. The method of claim 13 wherein the second COUNT-C parameter comprises:
    a RLC HFN;
    a RLC SN for the PDU; and
    a RLC sub-PDU SN.
  18. 18. The method of claim 17 wherein the sub-PDU SN further comprises zeros or is automatically padded to zeros during ciphering for providing an initial PDU.
  19. 19. A method to process a packet unit (PU) in a radio link control (RLC) layer for transmission, the method comprising:
    performing a ciphering process on an upper layer PU in the RLC layer or in an RLC module/implementation to generate the RLC PU buffering the RLC PU;
    re-segmenting of the RLC PU in the buffer; and
    transmitting re-segmented RLC PU.
  20. 20. The method of claim 19 wherein the ciphering process is an exclusive or (XOR) operation of the upper layer PU with a ciphering mask produced by the ciphering process, whereby a COUNT-C parameter is used as an input for generating the ciphering mask.
  21. 21. The method of claim 20 wherein the COUNT-C parameter comprises:
    a hyper frame number (HFN) and a sequence number (SN).
  22. 22. The method of claim 21 wherein the upper layer PU comprises:
    a packet data convergence protocol packet data unit (PDCP PDU) ciphered using a ciphering process that utilizes the HFN and the SN, and the SN comprises a PDCP PDU SN.
  23. 23. The method of 21 wherein the upper layer PU comprises:
    a packet data convergence protocol packet data unit (PDCP PDU) payload, whereby the PDU payload without a PDCP PDU header is ciphered using a ciphering process that utilizes the HFN and the SN, and the SN comprises a PDCP PDU SN.
  24. 24. The method of claim 21 further comprising:
    providing the RLC layer with a non-ciphered RLC SDU.
  25. 25. The method of claim 24 wherein the non-ciphered RLC SDU is processed in the RLC layer by ciphering RLC service data unit (SDU) using a ciphering process that utilizes the HFN and the SN, and the HFN comprises a RLC HFN, and the SN comprises a RLC SDU SN.
  26. 26. The method of claim 22 wherein the PU comprises at least one PDU.
  27. 27. The method of claim 23 wherein the PU comprises at least one PDU.
  28. 28. The method of claim 25 wherein the PU comprises at least one SDU.
  29. 29. The method of claim 26 wherein the re-segmenting of the PU comprises segmenting into at least one sub-PDU.
  30. 30. The method of claim 27 wherein the re-segmenting of the PU comprises segmenting into at least one sub-PDU.
  31. 31. The method of claim 28 wherein the re-segmenting of the PU comprises segmenting into at least one sub-PDU.
  32. 32. The method of claim 29 wherein the COUNT-C parameter comprises:
    the HFN; and
    the PDCP PDU SN.
  33. 33. The method of claim 30 wherein the COUNT-C parameter comprises:
    the HFN; and
    the PDCP PDU SN.
  34. 34. The method of claim 31 wherein the COUNT-C parameter comprises:
    the HFN; and
    the RLC SDU SN.
  35. 35. The method of claim 34 wherein the COUNT-C parameter comprises a predetermined number of bits.
  36. 36. A method to process a medium access control (MAC) packet unit (PU) for transmission, the method comprising:
    buffering the MAC PU;
    performing a MAC ciphering process on the MAC PU; and
    transmitting the ciphered MAC PU.
  37. 37. The method of claim 36 wherein the MAC PU comprises at least one or more radio link control packet data units (RLC PDU).
  38. 38. The method of claim 37 wherein the MAC ciphering process is an exclusive or (XOR) operation of the MAC PU with a MAC ciphering mask produced by the MAC ciphering process whereby a MAC COUNT-C parameter is used as an input for generating the ciphering mask.
  39. 39. The method of claim 38 wherein the MAC COUNT-C parameter comprises:
    a MAC hyper frame number (HFN); and
    a MAC Transmission sequence number (SN).
  40. 40. The method of claim 39 further comprises:
    multiplexing and ciphering the MAC PU, the multiplexed and ciphered MAC PU undergoes a hybrid automatic repeat request (HARQ) process for retransmission.
  41. 41. The method of claim 40 wherein the MAC Transmission SN is assigned.
  42. 42. The method of claim 40 wherein the MAC Transmission SN is incremented every time a new MAC PU is created.
  43. 43. A wireless transmit/receive unit (WTRU), the WTRU comprising:
    a processor to store at least one packet unit (PU), the processor configured to re-segment the PU and perform a ciphering process on the PU or the re-segmented PU, and provide a signal including the processed PU; and
    a transmitter configured to transmit the signal.
  44. 44. The WTRU of claim 43 wherein the ciphering process is an exclusive or (XOR) operation of the PU with a ciphering mask produced by the ciphering process utilizes a first COUNT-C parameter,
    wherein the first COUNT-C parameter comprises a radio link controller (RLC) hyper frame number (HFN) and a RLC sequence number (SN).
  45. 45. The WTRU of claim 44 wherein the PU comprises of at least one service data unit (SDU).
  46. 46. The WTRU of claim 45 wherein the re-segmenting of the PU comprises segmenting into at least one sub-SDU.
  47. 47. The WTRU of claim 46 wherein the segments of the sub-SDU utilizes a second COUNT-C parameter for ciphering the segments of the sub-SDU.
  48. 48. The WTRU of claim 47 wherein the second COUNT-C parameter comprises:
    a RLC HFN;
    a RLC SN for the SDU;
    a segment offset; and
    a length of the sub-SDU.
  49. 49. The WTRU of claim 48 wherein the segment offset is a location of a first byte position of the sub-SDU from a predetermined location in the re-segmented PU.
  50. 50. The WTRU of claim 49 wherein the length of the sub-SDU comprises the total number of bytes of the sub-SDU.
  51. 51. The WTRU of claim 44 wherein the PU comprises at least one protocol data unit (PDU).
  52. 52. The WTRU of claim 51 wherein the re-segmenting of the PU comprises segmenting into at least one sub-PDU.
  53. 53. The WTRU of claim 52 wherein segments of the sub-PDU utilizes a second COUNT-C parameter for ciphering the segments of the sub-PDU.
  54. 54. The WTRU of claim 53 wherein the second COUNT-C parameter comprises:
    a RLC HFN;
    a RLC SN for the PDU;
    a segment offset; and
    a length of the sub-PDU.
  55. 55. The WTRU of claim 54 wherein the segment offset is a location of a first byte position of the sub-PDU from a predetermined location in the re-segmented PU.
  56. 56. The WTRU of claim 54 wherein the length of the sub-PDU comprises the total number of bytes of the sub-PDU.
  57. 57. The WTRU of claim 53 wherein the second COUNT-C parameter comprises:
    a RLC HFN;
    a RLC SN for the PDU; and
    a RLC sub-PDU SN.
  58. 58. A wireless transmit/receive unit (WTRU), the WTRU comprising:
    a processor configured to perform ciphering on an upper layer packet unit (PU) in a radio link control (RLC) layer or on an upper layer PU in an RLC module/implementation to generate an RLC PU;
    the processor storing the RLC PU, re-segmenting the RLC PU and providing a signal including the processed RLC PU; and
    a transmitter configured to transmit the signal.
  59. 59. The WTRU of claim 58 wherein the ciphering is an exclusive or (XOR) operation of the upper layer PU with a ciphering mask produced by the ciphering whereby a COUNT-C parameter is used as an input for generating the ciphering mask.
  60. 60. The WTRU of claim 59 wherein the COUNT-C parameter comprises:
    a hyper frame number (HFN) and a sequence number (SN).
  61. 61. The WTRU of claim 60 wherein the upper layer PU comprises:
    a packet data convergence protocol packet data unit (PDCP PDU) ciphered using a ciphering process that utilizes the HFN and the SN, and the SN comprises a PDCP PDU SN.
  62. 62. The WTRU of 60 wherein the upper layer PU comprises:
    a packet data convergence protocol packet data unit (PDCP PDU) payload, whereby the PDU payload without a PDCP PDU header is ciphered using a ciphering process that utilizes the HFN and the SN, and the SN comprises a PDCP PDU SN.
  63. 63. The WTRU of claim 60 further comprises:
    providing the RLC layer with a non-ciphered RLC service data unit (SDU).
  64. 64. The WTRU of claim 63 wherein the non-ciphered RLC SDU is processed in the RLC layer by ciphering RLC service data unit (SDU) using a ciphering process that utilizes the HFN and the SN, and the HFN comprises a RLC HFN, and the SN comprises a RLC SDU SN.
  65. 65. The WTRU of claim 61 wherein the PU is made up of at least one PDU.
  66. 66. The WTRU of claim 62 wherein the PU is made up of at least one SDU.
  67. 67. The WTRU of claim 64 wherein the PU is made up of at least one PDU.
  68. 68. The WTRU of claim 65 wherein the re-segmenting of the PU comprises segmenting into at least one sub-PDU.
  69. 69. The WTRU of claim 66 wherein the re-segmenting of the PU comprises segmenting into at least one sub-PDU.
  70. 70. The WTRU of claim 67 wherein the re-segmenting of the PU comprises segmenting into at least one sub-PDU.
  71. 71. A wireless transmit/receive unit (WTRU), the WTRU comprising:
    a processor configured to perform a medium access control (MAC) ciphering process on a MAC packet unit (PU);
    the processor storing the MAC PU and providing a signal including the processed MAC PU; and
    a transmitter configured to transmit the signal.
  72. 72. The WTRU of claim 71 wherein the MAC PU comprises at least one or more radio link control packet data units (RLC PDU).
  73. 73. The WTRU of claim 72 wherein the MAC ciphering process is an exclusive or (XOR) operation of the MAC PU with a MAC ciphering mask produced by the MAC ciphering process whereby a MAC COUNT-C parameter is used as an input for generating the ciphering mask.
  74. 74. The WTRU of claim 73 further comprises:
    multiplexing and ciphering the ciphered MAC PU, the multiplexed and ciphered MAC undergoes a hybrid automatic repeat request (HARQ) process for transmission.
  75. 75. The WTRU of claim 74 wherein the MAC COUNT-C parameter comprises:
    a MAC hyper frame number (HFN); and
    a MAC Transmission sequence number (SN).
US12048120 2007-03-15 2008-03-13 Method and apparatus for ciphering packet units in wireless communications Abandoned US20080226074A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US89513407 true 2007-03-15 2007-03-15
US12048120 US20080226074A1 (en) 2007-03-15 2008-03-13 Method and apparatus for ciphering packet units in wireless communications

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US12048120 US20080226074A1 (en) 2007-03-15 2008-03-13 Method and apparatus for ciphering packet units in wireless communications
US14302070 US20140294179A1 (en) 2007-03-15 2014-06-11 Method and apparatus for ciphering packet units in wireless communications

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14302070 Continuation US20140294179A1 (en) 2007-03-15 2014-06-11 Method and apparatus for ciphering packet units in wireless communications

Publications (1)

Publication Number Publication Date
US20080226074A1 true true US20080226074A1 (en) 2008-09-18

Family

ID=39762716

Family Applications (2)

Application Number Title Priority Date Filing Date
US12048120 Abandoned US20080226074A1 (en) 2007-03-15 2008-03-13 Method and apparatus for ciphering packet units in wireless communications
US14302070 Pending US20140294179A1 (en) 2007-03-15 2014-06-11 Method and apparatus for ciphering packet units in wireless communications

Family Applications After (1)

Application Number Title Priority Date Filing Date
US14302070 Pending US20140294179A1 (en) 2007-03-15 2014-06-11 Method and apparatus for ciphering packet units in wireless communications

Country Status (1)

Country Link
US (2) US20080226074A1 (en)

Cited By (31)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080273537A1 (en) * 2007-05-01 2008-11-06 Qualcomm Incorporated Ciphering sequence number for an adjacent layer protocol in data packet communications
US20090003283A1 (en) * 2007-05-07 2009-01-01 Qualcomm Incorporated Re-using sequence number by multiple protocols for wireless communication
US20090034507A1 (en) * 2007-08-01 2009-02-05 Broadcom Corporation High-speed uplink packet access (hsupa) cipher multiplexing engine
US20090220079A1 (en) * 2005-06-15 2009-09-03 Ntt Docomo, Inc. Concealing device and concealing method
WO2010036154A1 (en) * 2008-09-23 2010-04-01 Telefonaktiebolaget L M Ericsson (Publ) Rlc segmentation for carrier aggregation
US20100158044A1 (en) * 2008-12-22 2010-06-24 Qualcomm Incorporated Method and apparatus for bundling and ciphering data
US20100157904A1 (en) * 2008-12-24 2010-06-24 Qualcomm Incorporated Optimized header for efficient processing of data packets
US20100165936A1 (en) * 2008-12-22 2010-07-01 Qualcomm Incorporated PRE-BUNDLING OF RLC SDUs IN THE RLC LAYER
US20100195640A1 (en) * 2007-09-28 2010-08-05 Sung Jun Park Method of performing uplink time alignment in wireless communication system
US20100202613A1 (en) * 2009-01-07 2010-08-12 Qualcomm Incorporated Packet bundling at the pdcp layer with ciphering on the pdcp sdu
US20100202614A1 (en) * 2009-02-09 2010-08-12 Samsung Electronics Co. Ltd. Apparatus and method for ciphering of uplink data in mobile communication system
US20100208686A1 (en) * 2007-10-17 2010-08-19 Sung-Duck Chun Method of providing circuit switched (sc) service using high-speed downlink packet access (hsdpa) or high-speed uplink packet access (hsupa)
US20100215006A1 (en) * 2009-01-29 2010-08-26 Qualcomm Incorporated Rlc for multi-carrier lte systems
US20100232356A1 (en) * 2009-03-16 2010-09-16 Qualcomm Incorporated Layer two segmentation techniques for high data rate transmissions
US20100255859A1 (en) * 2007-09-13 2010-10-07 Sung Jun Park method for providing control information using the paging procedure
WO2010123230A2 (en) * 2009-04-21 2010-10-28 엘지전자 주식회사 Efficient security-related processing
US20100285791A1 (en) * 2007-08-09 2010-11-11 Nokia Siemens Networks Oy Mobile communication terminal, communication station, communication network, and communication method
US20100284376A1 (en) * 2008-01-07 2010-11-11 Sung-Jun Park Method for reconfiguring time alignment timer
US20110044243A1 (en) * 2008-01-04 2011-02-24 Seung-June Yi Harq operation method for retransmitted data
US20130003542A1 (en) * 2011-07-01 2013-01-03 Qualcomm Incorporated Methods and apparatus for enhanced ul rlc flow control for mrab calls
US20130019111A1 (en) * 2010-03-31 2013-01-17 British Telecommunications Public Limited Company Secure data recorder
US8705527B1 (en) 2011-01-14 2014-04-22 Cisco Technology, Inc. System and method for internal networking, data optimization and dynamic frequency selection in a vehicular environment
US8873535B2 (en) 2011-09-26 2014-10-28 Qualcomm Incorporated Systems, methods and apparatus for retransmitting protocol data units in wireless communications
US20150195850A1 (en) * 2012-09-17 2015-07-09 Huawei Technologies Co., Ltd. Scheduling method, base station, user equipment, and system
US20150264675A1 (en) * 2007-05-09 2015-09-17 Samsung Electronics Co., Ltd. Method and apparatus for layer 2 arq for packets
US9232482B2 (en) 2011-07-01 2016-01-05 QUALOCOMM Incorporated Systems, methods and apparatus for managing multiple radio access bearer communications
US9591593B2 (en) 2011-07-22 2017-03-07 Qualcomm Incorporated Systems, methods and apparatus for radio uplink power control
US9686046B2 (en) 2011-09-13 2017-06-20 Qualcomm Incorporated Systems, methods and apparatus for wireless condition based multiple radio access bearer communications
US9794930B1 (en) * 2016-01-15 2017-10-17 Mbit Wireless, Inc. Method and apparatus for packet data unit processing for retransmission
US9843655B1 (en) 2016-01-11 2017-12-12 Mbit Wireless, Inc. Method and apparatus for packet data unit processing
US9930569B2 (en) 2011-08-04 2018-03-27 Qualcomm Incorporated Systems, methods and apparatus for wireless condition based multiple radio access bearer communications

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20180049888A (en) * 2016-11-04 2018-05-14 삼성전자주식회사 Method and apparatus to efficiently support both PDCP and DRX operations in the mobile communication system

Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020126629A1 (en) * 2001-02-09 2002-09-12 Jiang Sam Shiaw-Shiang Determination of acceptable sequence number ranges in a communications protocol
US20030039229A1 (en) * 2001-08-22 2003-02-27 Nokia Mobile Phones Ltd Method and apparatus implementing retransmission in a communication system providing H-ARQ
US20050021945A1 (en) * 2001-10-24 2005-01-27 Valtteri Niemi Ciphering as a part of the multicast concept
US6870932B2 (en) * 2001-05-07 2005-03-22 Asustek Computer Inc. Frame number identification and ciphering activation time synchronization for a wireless communications protocol
US20060251105A1 (en) * 2005-02-07 2006-11-09 Samsung Electronics Co., Ltd. Method and apparatus for requesting/transmitting status report of a mobile communication system
US7197145B2 (en) * 2001-04-07 2007-03-27 Lg Electronics Inc. Method for setting up radio bearer in mobile communication system
US20070171857A1 (en) * 2005-12-22 2007-07-26 Interdigital Technology Corporation Method and apparatus for data security and automatic repeat request implementation in a wireless communication system
US20080101312A1 (en) * 2006-10-31 2008-05-01 Takashi Suzuki Method and Apparatus for Resegmentation of Packet Data for Retransmission on HARQ Transmission Failure
US20080137652A1 (en) * 2002-11-08 2008-06-12 Koninklijke Philips Electronics N.V. Data Packet Transmission in a Single Container
US7551596B2 (en) * 2004-11-09 2009-06-23 Samsung Electronics Co., Ltd. Method and apparatus for signaling control information of uplink packet data service in mobile communication system
US7633899B2 (en) * 2001-08-14 2009-12-15 Samsung Electronics Co., Ltd Method for transmitting and receiving common information in a CDMA communication system providing HSDPA service
US7733914B2 (en) * 2004-06-23 2010-06-08 Koninklijke Philips Electronics N.V. Method of, and system for, communicating data, and a station for transmitting data
US20100172445A1 (en) * 2005-03-29 2010-07-08 Koninklijke Philips Electronics, N.V. Receiver apparatus and method for receiving data units over a channel
US7813361B2 (en) * 2004-11-03 2010-10-12 Samsung Electronics Co., Ltd System and method for transmitting/receiving hybrid automatic repeat request buffer capability information in broadband wireless access communication system
US7839894B2 (en) * 2000-10-07 2010-11-23 Lg Electronics Inc. Radio communication system and method having a radio link control layer
US7860125B2 (en) * 2008-01-28 2010-12-28 Cisco Techology, Inc. Flexible time stamping
US7869461B2 (en) * 2004-06-15 2011-01-11 Panasonic Corporation Scheduling mode dependent data transmissions
US7924710B2 (en) * 2003-09-05 2011-04-12 Mitsubishi Denki Kabushiki Kaisha Method for transmitting data including an error control mechanism designed for unreliable networks and error resilience applications
US8111668B2 (en) * 2003-02-14 2012-02-07 Alcatel Lucent Signaling methods for wireless communication systems

Family Cites Families (15)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI110651B (en) * 2000-02-22 2003-02-28 Nokia Corp A method for checking the amount of data transferred
KR100765123B1 (en) * 2002-02-16 2007-10-11 엘지전자 주식회사 Method for relocating SRNS
US20030206534A1 (en) * 2002-05-03 2003-11-06 Wu Frank Chih-Hsiang Scheme to handle radio link control service data units upon reception of a radio link control reset or reset acknowledge protocol data unit in a wireless communication system
EP1510017B1 (en) * 2002-06-05 2012-03-28 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Synchronizing method and apparatus using error detection of sequence numbers to avoid synchronizing failure
US20030236085A1 (en) * 2002-06-21 2003-12-25 Chi-Fong Ho Method for synchronizing a security start value in a wireless communications network
US7254144B2 (en) * 2002-06-21 2007-08-07 Innovative Sonic Limited Method for synchronizing a start value for security in a wireless communications network
US7068636B2 (en) * 2002-06-21 2006-06-27 Asustek Computer Inc. Method for determining RLC entity re-establishment during SRNS relocation
FI20031853A (en) * 2003-12-18 2005-06-19 Nokia Corp The data transfer method for wireless packet data based communication
US8254921B2 (en) * 2004-08-12 2012-08-28 Qualcomm Incorporated Default configurations with differential encoding in a wireless communication system
EP1708413A1 (en) * 2005-03-29 2006-10-04 Lg Electronics Inc. Multimedia broadcast/multicast service (MBMS) cells reconfigurations
US8228917B2 (en) * 2005-04-26 2012-07-24 Qualcomm Incorporated Method and apparatus for ciphering and re-ordering packets in a wireless communication system
US7813505B2 (en) * 2006-06-28 2010-10-12 Nokia Corporation Sequence number synchronization for ciphering
US8335189B2 (en) * 2007-09-28 2012-12-18 Interdigital Patent Holdings, Inc. Operation of control protocol data units in packet data convergence protocol
US8208498B2 (en) * 2007-10-30 2012-06-26 Qualcomm Incorporated Methods and systems for HFN handling at inter-base station handover in mobile communication networks
US8724548B2 (en) * 2010-04-22 2014-05-13 Qualcomm Incorporated Counter check procedure for packet data transmission

Patent Citations (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7839894B2 (en) * 2000-10-07 2010-11-23 Lg Electronics Inc. Radio communication system and method having a radio link control layer
US20020126629A1 (en) * 2001-02-09 2002-09-12 Jiang Sam Shiaw-Shiang Determination of acceptable sequence number ranges in a communications protocol
US7197145B2 (en) * 2001-04-07 2007-03-27 Lg Electronics Inc. Method for setting up radio bearer in mobile communication system
US6870932B2 (en) * 2001-05-07 2005-03-22 Asustek Computer Inc. Frame number identification and ciphering activation time synchronization for a wireless communications protocol
US7633899B2 (en) * 2001-08-14 2009-12-15 Samsung Electronics Co., Ltd Method for transmitting and receiving common information in a CDMA communication system providing HSDPA service
US20030039229A1 (en) * 2001-08-22 2003-02-27 Nokia Mobile Phones Ltd Method and apparatus implementing retransmission in a communication system providing H-ARQ
US20050021945A1 (en) * 2001-10-24 2005-01-27 Valtteri Niemi Ciphering as a part of the multicast concept
US20080137652A1 (en) * 2002-11-08 2008-06-12 Koninklijke Philips Electronics N.V. Data Packet Transmission in a Single Container
US8111668B2 (en) * 2003-02-14 2012-02-07 Alcatel Lucent Signaling methods for wireless communication systems
US7924710B2 (en) * 2003-09-05 2011-04-12 Mitsubishi Denki Kabushiki Kaisha Method for transmitting data including an error control mechanism designed for unreliable networks and error resilience applications
US7869461B2 (en) * 2004-06-15 2011-01-11 Panasonic Corporation Scheduling mode dependent data transmissions
US7733914B2 (en) * 2004-06-23 2010-06-08 Koninklijke Philips Electronics N.V. Method of, and system for, communicating data, and a station for transmitting data
US7813361B2 (en) * 2004-11-03 2010-10-12 Samsung Electronics Co., Ltd System and method for transmitting/receiving hybrid automatic repeat request buffer capability information in broadband wireless access communication system
US7551596B2 (en) * 2004-11-09 2009-06-23 Samsung Electronics Co., Ltd. Method and apparatus for signaling control information of uplink packet data service in mobile communication system
US20060251105A1 (en) * 2005-02-07 2006-11-09 Samsung Electronics Co., Ltd. Method and apparatus for requesting/transmitting status report of a mobile communication system
US20100172445A1 (en) * 2005-03-29 2010-07-08 Koninklijke Philips Electronics, N.V. Receiver apparatus and method for receiving data units over a channel
US20070171857A1 (en) * 2005-12-22 2007-07-26 Interdigital Technology Corporation Method and apparatus for data security and automatic repeat request implementation in a wireless communication system
US20080101312A1 (en) * 2006-10-31 2008-05-01 Takashi Suzuki Method and Apparatus for Resegmentation of Packet Data for Retransmission on HARQ Transmission Failure
US7860125B2 (en) * 2008-01-28 2010-12-28 Cisco Techology, Inc. Flexible time stamping

Cited By (74)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090220079A1 (en) * 2005-06-15 2009-09-03 Ntt Docomo, Inc. Concealing device and concealing method
US8358669B2 (en) 2007-05-01 2013-01-22 Qualcomm Incorporated Ciphering sequence number for an adjacent layer protocol in data packet communications
US20080273537A1 (en) * 2007-05-01 2008-11-06 Qualcomm Incorporated Ciphering sequence number for an adjacent layer protocol in data packet communications
US20090003283A1 (en) * 2007-05-07 2009-01-01 Qualcomm Incorporated Re-using sequence number by multiple protocols for wireless communication
US8331399B2 (en) * 2007-05-07 2012-12-11 Qualcomm Incorporated Re-using sequence number by multiple protocols for wireless communication
US20150264675A1 (en) * 2007-05-09 2015-09-17 Samsung Electronics Co., Ltd. Method and apparatus for layer 2 arq for packets
US9674832B2 (en) * 2007-05-09 2017-06-06 Samsung Electronics Co., Ltd Method and apparatus for layer 2 ARQ for packets
US20090034507A1 (en) * 2007-08-01 2009-02-05 Broadcom Corporation High-speed uplink packet access (hsupa) cipher multiplexing engine
US7949012B2 (en) * 2007-08-01 2011-05-24 Broadcom Corporation High-speed uplink packet access (HSUPA) cipher multiplexing engine
US20100285791A1 (en) * 2007-08-09 2010-11-11 Nokia Siemens Networks Oy Mobile communication terminal, communication station, communication network, and communication method
US8768383B2 (en) 2007-09-13 2014-07-01 Lg Electronics Inc. Method for providing control information using the paging procedure
US20100255859A1 (en) * 2007-09-13 2010-10-07 Sung Jun Park method for providing control information using the paging procedure
US8432811B2 (en) 2007-09-28 2013-04-30 Lg Electronics Inc. Method of performing uplink time alignment in wireless communication system
US20100195640A1 (en) * 2007-09-28 2010-08-05 Sung Jun Park Method of performing uplink time alignment in wireless communication system
US20100208686A1 (en) * 2007-10-17 2010-08-19 Sung-Duck Chun Method of providing circuit switched (sc) service using high-speed downlink packet access (hsdpa) or high-speed uplink packet access (hsupa)
US8619760B2 (en) * 2007-10-17 2013-12-31 Lg Electronics Inc. Method of providing circuit switched (SC) service using high-speed downlink packet access (HSDPA) or high-speed uplink packet access (HSUPA)
US8670377B2 (en) 2008-01-04 2014-03-11 Lg Electronics Inc. HARQ operation method for retransmitted data
US20110044243A1 (en) * 2008-01-04 2011-02-24 Seung-June Yi Harq operation method for retransmitted data
US20100284376A1 (en) * 2008-01-07 2010-11-11 Sung-Jun Park Method for reconfiguring time alignment timer
US9066290B2 (en) 2008-01-07 2015-06-23 Lg Electronics Inc. Method for reconfiguring time alignment timer
US20110164664A1 (en) * 2008-09-23 2011-07-07 Telefonaktiebolaget L M Ericsson (Publ) RLC Segmentation for Carrier Aggregation
US9338690B2 (en) 2008-09-23 2016-05-10 Telefonaktiebolaget Lm Ericsson (Publ) RLC segmentation for carrier aggregation
WO2010036154A1 (en) * 2008-09-23 2010-04-01 Telefonaktiebolaget L M Ericsson (Publ) Rlc segmentation for carrier aggregation
US8743905B2 (en) * 2008-12-22 2014-06-03 Qualcomm Incorporated Method and apparatus for bundling and ciphering data
US20100158044A1 (en) * 2008-12-22 2010-06-24 Qualcomm Incorporated Method and apparatus for bundling and ciphering data
WO2010075453A3 (en) * 2008-12-22 2010-09-30 Qualcomm Incorporated Method and apparatus for bundling and ciphering data
US8335205B2 (en) 2008-12-22 2012-12-18 Qualcomm Incorporated Pre-bundling of RLC SDUs in the RLC layer
US20100165936A1 (en) * 2008-12-22 2010-07-01 Qualcomm Incorporated PRE-BUNDLING OF RLC SDUs IN THE RLC LAYER
WO2010075457A2 (en) * 2008-12-24 2010-07-01 Qualcomm Incorporated Optimized header for efficient processing of data packets
CN102265701A (en) * 2008-12-24 2011-11-30 高通股份有限公司 For efficient processing of data packet header optimization
US20100157904A1 (en) * 2008-12-24 2010-06-24 Qualcomm Incorporated Optimized header for efficient processing of data packets
KR101270121B1 (en) * 2008-12-24 2013-05-31 퀄컴 인코포레이티드 Optimized header for efficient processing of data packets
WO2010075457A3 (en) * 2008-12-24 2010-09-30 Qualcomm Incorporated Optimized header for efficient processing of data packets
US9554417B2 (en) * 2008-12-24 2017-01-24 Qualcomm Incorporated Optimized header for efficient processing of data packets
US20100202613A1 (en) * 2009-01-07 2010-08-12 Qualcomm Incorporated Packet bundling at the pdcp layer with ciphering on the pdcp sdu
WO2010080912A3 (en) * 2009-01-07 2010-10-07 Qualcomm Incorporated Packet bundling at the pdcp layer with ciphering on the pdcp sdu
US20100215006A1 (en) * 2009-01-29 2010-08-26 Qualcomm Incorporated Rlc for multi-carrier lte systems
US8638773B2 (en) * 2009-01-29 2014-01-28 Qualcomm Incorporated RLC for multi-carrier LTE systems
US20100202614A1 (en) * 2009-02-09 2010-08-12 Samsung Electronics Co. Ltd. Apparatus and method for ciphering of uplink data in mobile communication system
US8953781B2 (en) * 2009-02-09 2015-02-10 Samsung Electronics Co., Ltd. Apparatus and method for ciphering of uplink data in mobile communication system
KR101339129B1 (en) * 2009-03-16 2013-12-09 퀄컴 인코포레이티드 Layer two segmentation techniques for high data rate transmissions
US20100232356A1 (en) * 2009-03-16 2010-09-16 Qualcomm Incorporated Layer two segmentation techniques for high data rate transmissions
WO2010123230A3 (en) * 2009-04-21 2011-01-06 엘지전자 주식회사 Efficient security-related processing
KR20100116132A (en) * 2009-04-21 2010-10-29 엘지전자 주식회사 Efficient security related procedure
US8811617B2 (en) 2009-04-21 2014-08-19 Lg Electronics Inc. Efficient security-related processing
WO2010123230A2 (en) * 2009-04-21 2010-10-28 엘지전자 주식회사 Efficient security-related processing
KR101674947B1 (en) 2009-04-21 2016-11-10 엘지전자 주식회사 Efficient Security Related Procedure
US9208333B2 (en) * 2010-03-31 2015-12-08 British Telecommunications Public Limited Company Secure data recorder
US20130019111A1 (en) * 2010-03-31 2013-01-17 British Telecommunications Public Limited Company Secure data recorder
US9654937B2 (en) 2011-01-14 2017-05-16 Cisco Technology, Inc. System and method for routing, mobility, application services, discovery, and sensing in a vehicular network environment
US9036509B1 (en) 2011-01-14 2015-05-19 Cisco Technology, Inc. System and method for routing, mobility, application services, discovery, and sensing in a vehicular network environment
US8989954B1 (en) 2011-01-14 2015-03-24 Cisco Technology, Inc. System and method for applications management in a networked vehicular environment
US9860709B2 (en) 2011-01-14 2018-01-02 Cisco Technology, Inc. System and method for real-time synthesis and performance enhancement of audio/video data, noise cancellation, and gesture based user interfaces in a vehicular environment
US9083581B1 (en) 2011-01-14 2015-07-14 Cisco Technology, Inc. System and method for providing resource sharing, synchronizing, media coordination, transcoding, and traffic management in a vehicular environment
US8903593B1 (en) 2011-01-14 2014-12-02 Cisco Technology, Inc. System and method for analyzing vehicular behavior in a network environment
US9888363B2 (en) 2011-01-14 2018-02-06 Cisco Technology, Inc. System and method for applications management in a networked vehicular environment
US8863256B1 (en) 2011-01-14 2014-10-14 Cisco Technology, Inc. System and method for enabling secure transactions using flexible identity management in a vehicular environment
US8848608B1 (en) 2011-01-14 2014-09-30 Cisco Technology, Inc. System and method for wireless interface selection and for communication and access control of subsystems, devices, and data in a vehicular environment
US9225782B2 (en) 2011-01-14 2015-12-29 Cisco Technology, Inc. System and method for enabling a vehicular access network in a vehicular environment
US8718797B1 (en) 2011-01-14 2014-05-06 Cisco Technology, Inc. System and method for establishing communication channels between on-board unit of vehicle and plurality of nodes
US9277370B2 (en) 2011-01-14 2016-03-01 Cisco Technology, Inc. System and method for internal networking, data optimization and dynamic frequency selection in a vehicular environment
US8705527B1 (en) 2011-01-14 2014-04-22 Cisco Technology, Inc. System and method for internal networking, data optimization and dynamic frequency selection in a vehicular environment
US9154900B1 (en) * 2011-01-14 2015-10-06 Cisco Technology, Inc. System and method for transport, network, translation, and adaptive coding in a vehicular network environment
US9232482B2 (en) 2011-07-01 2016-01-05 QUALOCOMM Incorporated Systems, methods and apparatus for managing multiple radio access bearer communications
US20130003542A1 (en) * 2011-07-01 2013-01-03 Qualcomm Incorporated Methods and apparatus for enhanced ul rlc flow control for mrab calls
US9167472B2 (en) * 2011-07-01 2015-10-20 Qualcomm Incorporated Methods and apparatus for enhanced UL RLC flow control for MRAB calls
US9591593B2 (en) 2011-07-22 2017-03-07 Qualcomm Incorporated Systems, methods and apparatus for radio uplink power control
US9930569B2 (en) 2011-08-04 2018-03-27 Qualcomm Incorporated Systems, methods and apparatus for wireless condition based multiple radio access bearer communications
US9686046B2 (en) 2011-09-13 2017-06-20 Qualcomm Incorporated Systems, methods and apparatus for wireless condition based multiple radio access bearer communications
US8873535B2 (en) 2011-09-26 2014-10-28 Qualcomm Incorporated Systems, methods and apparatus for retransmitting protocol data units in wireless communications
US9801200B2 (en) * 2012-09-17 2017-10-24 Huawei Technologies Co., Ltd. Scheduling method, base station, user equipment, and system
US20150195850A1 (en) * 2012-09-17 2015-07-09 Huawei Technologies Co., Ltd. Scheduling method, base station, user equipment, and system
US9843655B1 (en) 2016-01-11 2017-12-12 Mbit Wireless, Inc. Method and apparatus for packet data unit processing
US9794930B1 (en) * 2016-01-15 2017-10-17 Mbit Wireless, Inc. Method and apparatus for packet data unit processing for retransmission

Also Published As

Publication number Publication date Type
US20140294179A1 (en) 2014-10-02 application

Similar Documents

Publication Publication Date Title
US6842445B2 (en) Retransmission method with soft combining in a telecommunications system
US20080137652A1 (en) Data Packet Transmission in a Single Container
US20050138528A1 (en) Method, system and transmitting side protocol entity for sending packet data units for unacknowledged mode services
US6925298B2 (en) Initialization for hyper frame number of signaling radio bearers
US20090104890A1 (en) Operation of control protocol data units in packet data convergence protocol
US20080123655A1 (en) Apparatus and method for transmitting/receiving ciphered packet in mobile communication system
US20090086709A1 (en) Method and apparatus for enhanced transport format combination selection in wireless communications
US20090103445A1 (en) Method and apparatus for enhancing various pdcp and layer 2 operations
EP1337125A2 (en) Method for relocating SRNS in a mobile communication system
US20090003283A1 (en) Re-using sequence number by multiple protocols for wireless communication
US20070153793A1 (en) Method and apparatus of modifying integrity protection configuration in a mobile user equipment of a wireless communications system
US20030236085A1 (en) Method for synchronizing a security start value in a wireless communications network
US20090103478A1 (en) Method and apparatus for pcdp discard
US20030235212A1 (en) Method for synchronizing a START value for security in a wireless communication network
US20090034476A1 (en) Packet data convergence protocol procedures
US20080227442A1 (en) Wireless communication method and apparatus for supporting reconfiguration of radio link control parameters
US20100235634A1 (en) Security considerations for the lte of umts
US20090168723A1 (en) Method and apparatus for handling out-of-order packets during handover in a wireless communication system
US20090111423A1 (en) Non-access stratum architecture and protocol enhancements for long term evolution mobile units
US20070291788A1 (en) Method and apparatus for reducing transmission overhead
US20080225893A1 (en) Acknowledged mode radio link control architecture and method within evolved hspa systems
US20070258591A1 (en) Ciphering control and synchronization in a wireless communication system
US20070041382A1 (en) Method and apparatus for ciphering and re-ordering packets in a wireless communication system
US20090149189A1 (en) Method and apparatus for supporting configuration and control of the rlc and pdcp sub-layers
US20090086708A1 (en) Method and apparatus for supporting segmentation of packets for uplink transmission

Legal Events

Date Code Title Description
AS Assignment

Owner name: INTERDIGITAL TECHNOLOGY CORPORATION, DELAWARE

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:SAMMOUR, MOHAMMED;SOMASUNDARAM, SHANKAR;WANG, PETER S.;AND OTHERS;REEL/FRAME:021121/0492;SIGNING DATES FROM 20080514 TO 20080609