[ns] Problem running Eurane

Wed May 11 10:23:50 PDT 2005

Hi Kamal, Chan and Neill,

I have a similar problem with UM mode in Eurane. I've patched version v.109 in 
ns-2.26, and AM mode runs OK, but UM doesn't. I'm working for solve it, but if 
you have some bug or fix, please, notify to me.

Regards,
Juan Antonio

Mensaje citado por kamal deep singh <kamal.singh at irisa.fr>:

 Hi Neill, Chan,

 I have some possible answers for you Chan.
 And Neill if you verify the changes which i sent in my last mail then please

 tell me.
 I changed um.cc and um-hs.cc and that were not related to my question about
 whether UMHS or UM was present in UE. They were related to segment, seqno,
 payloadSize_, etc..

 For your questions chan. (But, also check my other changes in previous 
 email.
 I have done more changes like below but, I am checking them. After checking 
 i will
  send the complete changes.)

 1) I put completePDU() in
  void UM::timeout(int tno, int flowID) of um.cc
 case RLC_TIMER_TTI:
         TTI_time_ = Scheduler::instance().clock();
         TTI_PDUs_ = (int) (bandwidth_ * TTI_) / (payloadSize_ * 8);
         tti_timer_.resched(TTI_);
         for (int i = 0; i < TTI_PDUs_; i++) {
            //send_packet_down
            Packet     *p = transmissionBuffer_.deque();

             if (p != NULL) {
 -              downtarget_->recv(p);
 +	     completePDU(p);
 +	     downtarget_->recv(p);
             }
          }

 2)for decoupling UM from TCP
 As i said in previous email , will it not be good to maintain a SDU seq 
 number in RLC?
 Neill, if you find it reasonable then tell me and I will try to put a SDU 
 seqno in RLC.

 Also Neill please check the following:
 the latest EURANE patch is ns-eurane-109.diff.gz on the EURANE website.
 But, from your descriptions it seems that some patches especially for UM 
 have already been done
 but not released. If you can compare ns-eurane-109.diff with your code then 
 it will be great.

 regards,
 kamal

 Hi Neill,  Kamal,

 I think my setting is a bit difference than Kamal.
 I'm sending a Ping packet from sgsn to ue using UM in common channel.
 Here are the problems I had come across so far.

 um.cc, recv():
 Problem: The last PDU's llh->eopno is never set to the seqno. The
 completePDU() is not used in um.cc at at all.
 Fix: Changed the comparison of llh->eopno() to EOPNO_TO_SEQNO in recc()
 Code:
          // if (temp_seqno == llh->eopno()) {

          if (llh->eopno() == EOPNO_TO_SEQNO) {
             // The packet is the last PDU of an SDU. Now, check whether the
             // complete SDU has been received. If so, pass the SDU up. In 
 either
             // case, the next expected packet will be the first PDU of the 
 next
             // SDU..

 This solution may have some unseen problems, the right way should
 somehow call the completePDU(), but I couldn't figure out where should
 make the call.

 um.cc, rev():
 Problem: Decouple UM from TCP, so UM can work with other agents.
 Fix: Comment out the check of nextExpectedSDU to temp_sdu.
 Code:

            // if (nextExpectedSeqno_ == temp_seqno && nextExpectedSDU_
 == temp_sdu
             //    && errorInSDU_ == 0) {
             if (nextExpectedSeqno_ == temp_seqno && errorInSDU_ == 0) {
                makeSDU(p);
             } else {
                Packet::free(p);
             }

 um.cc, timeout():
 Problem: The next SDU try to concat with a non-existing PDU.
 Fix: remove temporary packet after it is sent.
 Code:

    switch (tno) {
      case RLC_TIMER_TEMP_PDU:

         // Before we stored the temporary PDU in the
         // vector, we set the number of Length Indicators
         // and the number of bytes that could be
         // concatenated. Because we are not concatenating,
         // but padding we need one Length Indicator less,
         // thus we have to pad more.
         hdr_rlc::access(temporaryPacket_.p)->lengthInd_--;
         hdr_rlc::access(temporaryPacket_.p)->padding_ =
               temporaryPacket_.concat_data + lengthIndicatorSize_;
         enquePacket(temporaryPacket_.p);

         // hc: bug fix, remove temporary packet after it is sent
         temporaryPacket_.tempPDUTimer.cancel();
         temporaryPacket_.p = NULL;

 Please take a look at my solutions and see whether I had over look 
 something?
 Thanks a lot.

 P.S. Kamal, I'm going to try using HS-AM HS-UM tomorrow.  I'll take a
 look at your code change once I had encountered the same problem.

 Rgds,
 Horace Chan

 On 5/10/05, Neill Whillans <neill.whillans at ti-wmc.nl> wrote:
 > kamal deep singh wrote:
 >
 > >
 > > Hello Chan,
 > >
 > > I am also trying to debug EURANE. Finally I managed to see
 > > UM packets in trace. Problem was that packets were not being received.
 > >
 > > I am sending you the diff -ur result for new files. If you change
 > > accordingly then,
 > > you will be able to see UM packets.  Tell me if you disagree with some
 > > changes.
 > >
 > > Currently I am trying to solve the problem that UM packets start from
 > > RNC "UMHS" rlc in um-hs.cc
 > > but are recvd by "UM" of UE in um.cc (but, should be recvd in "UMHS"
 > > of UE).
 > > Do you think this is a routing problem?
 > >
 > >
 > > "hdr_tcp    *tcph = hdr_tcp::access(p);"
 > > int temp_sdu = tcph->seqno();
 > > Other thing I feel is that instead of checking TCP seqno when PDUs are
 > > recvd. The RLC should
 > > maintain its own SDU seqno so, that it doesnt depend on TCP. Because
 > > if anyother header instead of TCP is there
 > > then what will happen?
 > >
 > > below you will find the diff -ur output. I am still checking it and am
 > > not sure if everything below is ok.
 > >
 > > regards,
 > > kamal
 > >
 > >
 > >
 > Hi,
 >
 > I'm not sure what the problem is, as I have scripts running here that
 > receive UM packets.
 >
 > The reason why you have a UM-HS object at the RNC and a UM object at the
 > UE, is because they are functionally different. At the RNC the UM-HS is
 > handling all the flows connected through the HS-DSCH channel, whereas at
 > the UE the RLC only has to handle flows that belong to itself. This is
 > quite clearly shown (for the AM case) in the figures of the Appendix, in
 > the User Guide.
 >
 > If you feel you have found a bug or fix, please let us know, stating the
 > file, function and code snippet. I will do my best to check it and if
 > valid, release a new version.
 >
 > /Neill
 >
 > --
 > ------------------------------------------------
 > Neill Whillans
 > Advanced Signal Processing Engineer
 > Twente Institute for Wireless and Mobile Communications (WMC)
 > The Netherlands
 > http://www.ti-wmc.nl
 > ------------------------------------------------
 >
 >

 -- 
 Horace Chan
 Simon Fraser University
 http://www.horace.org 

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/