Re: [rohc] Support of ROHC Piggyback Feedback in LTE
Karthik Balaguru <Karthik.Balaguru@lntinfotech.com> Mon, 29 June 2009 14:18 UTC
Return-Path: <Karthik.Balaguru@lntinfotech.com>
X-Original-To: rohc@core3.amsl.com
Delivered-To: rohc@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64B9F3A6999; Mon, 29 Jun 2009 07:18:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.043
X-Spam-Level:
X-Spam-Status: No, score=-6.043 tagged_above=-999 required=5 tests=[AWL=0.555, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvFQSVX6gtXo; Mon, 29 Jun 2009 07:18:29 -0700 (PDT)
Received: from mail142.messagelabs.com (mail142.messagelabs.com [216.82.249.99]) by core3.amsl.com (Postfix) with SMTP id 024963A6B3A; Mon, 29 Jun 2009 07:18:28 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: Karthik.Balaguru@lntinfotech.com
X-Msg-Ref: server-14.tower-142.messagelabs.com!1246285116!33785523!5
X-StarScan-Version: 6.0.0; banners=lntinfotech.com,-,-
X-Originating-IP: [203.101.96.4]
Received: (qmail 27145 invoked from network); 29 Jun 2009 14:18:40 -0000
Received: from bangaloresmtp.lntinfotech.com (HELO bangaloresmtp.lntinfotech.com) (203.101.96.4) by server-14.tower-142.messagelabs.com with SMTP; 29 Jun 2009 14:18:40 -0000
Received: from Bangalore.lntinfotech.com ([172.28.0.3]) by bangaloresmtp.lntinfotech.com (Lotus Domino Release 7.0.3) with ESMTP id 2009062919502172-109863 ; Mon, 29 Jun 2009 19:50:21 +0530
In-Reply-To: <1246040957.4a45137dcf34e@www.sm.luth.se>
To: pelle@cdt.luth.se
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006
Message-ID: <OFE667A92C.01DDCDB7-ON652575E4.004AE5FE-652575E4.004E9A1C@lntinfotech.com>
From: Karthik Balaguru <Karthik.Balaguru@lntinfotech.com>
Date: Mon, 29 Jun 2009 19:48:32 +0530
X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 06/29/2009 07:48:35 PM, Serialize complete at 06/29/2009 07:48:35 PM, Itemize by SMTP Server on BangaloreSMTP/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 06/29/2009 07:50:21 PM, Serialize by Router on BangaloreSMTP/LNTINFOTECH(Release 7.0.3|September 26, 2007) at 06/29/2009 07:50:27 PM, Serialize complete at 06/29/2009 07:50:27 PM
Content-Type: multipart/alternative; boundary="=_alternative 004E9A19652575E4_="
Cc: rohc@ietf.org, rohc-bounces@ietf.org
Subject: Re: [rohc] Support of ROHC Piggyback Feedback in LTE
X-BeenThere: rohc@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Robust Header Compression <rohc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rohc>
List-Post: <mailto:rohc@ietf.org>
List-Help: <mailto:rohc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rohc>, <mailto:rohc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jun 2009 14:18:36 -0000
Hi Pelle, Thanks for your clarifications. I will be forwarding the 3GPP specific queries to 3GPP LTE Forum. PS : Based on your reply, i assume that Piggyback packet is a 'Compressed packet' each associated with one PDCP SDU. The query/dilemma was due to the 2 statements from Section 5.5.4 from TS36.323v850 that has been mentioned below :- " The header compression protocol generates two types of output packets: - compressed packets, each associated with one PDCP SDU - standalone packets not associated with a PDCP SDU, i.e. interspersed ROHC feedback packets " As the LTE PDCP standard does not explicitly talk about the piggyback packet , i think , the term 'Compressed packet' in the section 5.5.4 TS36.323v850 mentioned above refers to ' Rohc Feedback Packet and Rohc Compressed header (Piggybacked) '. It does not refer to 'Rohc Compressed header' alone. Thanks for your reply, Regards, Karthik Balaguru pelle@cdt.luth.se Sent by: rohc-bounces@ietf.org 06/26/2009 11:59 PM To Karthik Balaguru <Karthik.Balaguru@lntinfotech.com> cc rohc@ietf.org Subject Re: [rohc] Support of ROHC Piggyback Feedback in LTE Hello, Kind reminder - please note that this mailing list is for questions concerning IETF specifications handled by the ROHC WG. Questions related to 3GPP specifications may not receive any answers, and should be directed to the group responsible for those specifications. Wrt to the total length of the entire feedback information, my understanding is that it is derived by inspecting the first two octets of each feedback element in the ROHC packet. Cheers, ///Ghyslain PS: Regarding your 3GPP specific questions, let's hope the following can provide you with some useful guidance. For further questions, please turn to the proper forum. The following is my understanding of the LTE specs. For Rel-8 PDCP LTE as per TS36.323v860, if header compression is configured for the DRB by RRC at RB setup the following applies: the PDCP Data PDUs carry the entire ROHC packet (i.e. piggybacked feedback, if any, and the ROHC header and payload) in the data part of the PDCP PDU (see subclause 6.2.3 and 6.2.4 in particular); the PDCP Control PDU carries only interspersed ROHC feedback packets (see subclause 5.5.4 and 6.2.5 in particular). Ciphering in Rel-8 LTE PDCP is not applicable to PDCP Control PDUs (there is no associated PDCP SN), but ciphering is always applied to PDCP Data PDUs for DRBs (thus always covering both the piggybacked feedback, if any, and the rest of the ROHC packet). The compressor in the PDCP entity first assemble the ROHC packet (including any piggyback feedback from the decompressor), then PDCP ciphers the result as the data part of the PDCP PDU with the COUNT associated to the original, uncompressed SDU. ROHC is not applicable to SRBs. Quoting Karthik Balaguru <Karthik.Balaguru@lntinfotech.com>: > Hi, > > Need clarifications on ROHC Piggyback feedback support in LTE. > > LTE standrad states that PDCP Control Packet (Feedback) shall not be > ciphered (Reference - 3GPP TS 36.323 V8.5.0, Section 5.5.4 ) and PDCP data > > packets shall be ciphered by configured algorithm (Reference - Section > 5.2.1, 5.2.2 ) . > In case of Piggyback feedback packet, DataPacket will be attatched at the > end of feedback packet. (RFC 3095 - Page no 43,44 & Section 5.2.2) > 1. In LTE PDCP, If the Data Packet should be ciphered for these piggyback > packets , then how will the Peer entity generate COUNT input for ciphering > algorithm as PDCP-SN is not available ? > 2. In LTE PDCP, Can the data Packet be sent without ciphering in Piggyback > Feedback packets ? > > Further reference w.r.t RFC 3095 - Page no 44 > d) To allow piggybacking, 5), it is possible to deduce the length of > feedback information by examining the first few octets of the > feedback. This allows the decompressor to pass piggybacked feedback > information to the associated same-side compressor > without understanding its format. The length information decouples > the decompressor from the compressor in the sense that > the decompressor can process the compressed header immediately without > waiting for the compressor to hand it back after parsing > the feedback information. > > Kindly clarify regarding the support of RoHC piggyback Feedback in LTE ? > > Thx in advans, > Karthik Balaguru > > ______________________________________________________________________ _______________________________________________ Rohc mailing list Rohc@ietf.org https://www.ietf.org/mailman/listinfo/rohc ______________________________________________________________________ ______________________________________________________________________
- [rohc] Support of ROHC Piggyback Feedback in LTE Karthik Balaguru
- Re: [rohc] Support of ROHC Piggyback Feedback in … pelle
- Re: [rohc] Support of ROHC Piggyback Feedback in … Karthik Balaguru
- [rohc] SN Encoding clarification Karthik Balaguru
- Re: [rohc] SN Encoding clarification Ang Way Chuang
- Re: [rohc] SN Encoding clarification Karthik Balaguru
- Re: [rohc] SN Encoding clarification Ang Way Chuang