Generic selectors
Exact matches only
Search in title
Search in content
Search in posts
Search in pages

TBF assignment on CCCH

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #58415 Reply
    CM
    Guest

    Hi.

    I am developing a PCU. When I assign a downlink TBF over CCCH (either AGCH or PCH) I have found that the assignment is not always successful.

    In one example, I send the assignment on AGCH at frame 8880, then start sending data on the allocated PDTCH. The data does not get acknowledged (no PDAN), so I re-send the same assignment on frame 8982 (2x multiframes later. I am using combined SDCCH / CCCH, and BS_AG_BLKS_RES = 1) and this time I get PDAN in frame 9004, which is what should happen.

    The previous (uplink) TBF’s packet uplink ack was sent in frame 8788 and acknowledged in frame 8801, so the MS has had 79 frames to switch over to monitoring CCCH for assignment messages.

    I’m wondering if this is long enough, so my question is: Is there a specification that tells me how long the MS should be allowed to change from packet transfer mode to packet idle mode?

    #58416 Reply
    Pix
    Guest

    Hello CM,

    I won’t be able to give you the spec now, but yes, there is a timer to switch from listening the PACCH (PDCH) to the AGCH & PCH (CCCH).

    But the mechanism is rather complicateddepending on the situation . Are you sure that the DL TBF is fully released when the MS is sending UL data ?

    Once the MS has finished sending data in UL (and there is no DL TBF neither active nor delayed), the MS will enter a specific state of “extended phase”, if a certain timer is > 0. (I think the timer is called T DELAYED TBF POL… or T RESPONSE NETWORK TIME… but i can never remember this timer… I’m not sure)

    On the last useful UL RLC blocks, the PCU doesn’t acknowledge the reception (in PUAN, FBI = 0 instead of 1), in order for the MS to remain “aware”.

    During this time, the MS remains on the UL PDCH, sending “dummy” blocks in UL, if the PCU sends the USF.

    I’m sorry, it’s not a very precise description, but i need to check the documents to be more helpful. Tomorrow morning, i’ll do that 🙂

    Cheers,
    Pix

    #58417 Reply
    CM
    Guest

    Hmmm.. I’ll check the timing on the previous DL TBF – it could be that T3192 is still running in the MS, especially if the UL TBF went quickly, so when the second DL TBF is ready to go it would be assigned on PACCH rather than CCCH. My code makes certain assumptions at the moment, and doesn’t implement timers properly yet.

    If you can remember the timer name then that would be really helpful.

    Thanks.

    #58418 Reply
    Pan
    Guest

    Dear, CM! I am interesting in your previous research for UL assignment about 2 months ago:) Did you got success in it?

    Concerning your current question, I am thinking the following:
    MS changes its state from packet transfer to packet idle right after receiving Packet UL ACK (with RRBP valid and FBI=1) and sending PACKET CONTROL ACK.
    In turn Packet UL ACK (with RRBP valid and FBI=1) is sent to MS after receiving the last RLC/MAC block with CV=0.
    The description above is about non-extended UL TBF.
    In extended UL TBF mode the network does as Pix already said).
    There is a non-standard (vendor dependent) timer on network side (for that extended case) which supervises the instant of time when Packet UL ACK (with FBI=1) must be sent.

    #58419 Reply
    CM
    Guest

    Pan,

    Regarding the previous query, yes I got it sorted out. The problem at the time was that if I send 1 or 2 PDAs after sending PUAN then both are ignored, but if I send 3 PDAs after PUAN then I get PCAs for all three.

    I still don’t know why that happens, but once I’ve sent PUAN (with FBI set) then the MS considers the TBF ended, and it stops monitoring the PDCH. So strictly speaking I shouldn’t ever have received a PCA for the PDAs sent after PUAN. It may be a quirk of the handset firmware (Nokia) that the MS responds to the 3x PDAs even though it shouldn’t.

    Regarding the current thing, I’m only using non-extended mode TBFs, so things should be fairly straightforward. I am running with a short value of T3192 at the moment (80ms) so if I have a sequence of DL TBF 1 -> UL TBF -> DL TBF 2 then there should be no risk that DL TBF 1 is still active by the time I get to DL TBF 2. Still testing to see how it works out…

    #58420 Reply
    Pan
    Guest

    CM,
    some questions to you:
    – is the UL TBF Release procedure finished properly (i.e. with CV=0 from MS and FBI=1 from your side);
    – Are you assign DL TBF through the DL TBF Assignment message on AGCH or…? the sequence of messaging?
    – GMM state of the MS in the moment of assignment?

    #58421 Reply
    CM
    Guest

    1. Yes, the UL TBF is released OK. When I see CV=0 I send the final PUAN with FBI=1. I don’t do any downlink assignment until I see the PCA for the PUAN.

    2. The DL assignment is using CCCH, i.e. either AGCH or PCH depending on what comes first. I set the poll request in the DL assignment and set the TBF start time to be block 0 of the next-plus-one 26-multiframe. (For some reason I seem to get better results if I specify a TBF starting time than if I don’t. Not sure if that’s relevant.)

    3. Typically this is in GMM ready state.

    #58422 Reply
    Pan
    Guest

    CM,
    I think that DL transfer in Ready state may be initiated only by Immediate Assignment, see 44.018 (if PCCCH not present) on AGCH (not PCH).

    #58423 Reply
    CM
    Guest

    43.064 6.6.4.8.2 says that the Immediate Assignment is transmitted on CCCH if there is no PCCCH, i.e. it doesn’t specify AGCH or PCH. 44.018 is pretty much the same.

    I tried sending the PDA on AGCH only and PCH only just to verify that the MS responds in either case, and the MS doesn’t seem to care which one it gets the message from. Also my logs show that the problem happens when the assignment goes on AGCH (and also PCH, but mostly AGCH is used because of logical channel sequencing).

    #58424 Reply
    Pan
    Guest

    Well, CM:)
    I am also in doubt, but in the largest accounts it is not so important because AGCH and PCH are shared a block by block basis.
    I think that you may also check out the following:
    1)The DRX mode of the MS (DRX-mode or non-DRX mode after packet transfer->packet idle transition and non-DRX timer), if DRX mode is supported in your network. Really Immediate assignment Command on A-bis has no Paging Group info as in Paging command. and in DRX mode an MS is looking for only it’s own paging blocks (and not for AGCH blocks, defined by BS_AG_BLKS_RES). In non-DRX period after packet transfer->packet idle transition it observes all CCCH blocks in it’s CCCH group.
    2) Initial timing advance estimation for DL Ack from MS. Are you send TA in Immediate Ass? if no, then you must indicate to MS to send PACKET CONTROL ACKNOWLEDGEMENT in 4 random access burst form.

    #58425 Reply
    CM
    Guest

    Latest update on this is that I’m still not sure what’s happening with the downlink stuff. I am setting TA in the IMM_ASS and the DRX timer is set to something very long.

    I have noticed another thing and I would appreciate any insight.

    Many of the PDANs I receive have a Channel Request Description IE in them, which is normal, so I send a Packet Uplink Assignment in response. This was working fine.

    A recent change I made in the code, though, broke this. The change was that I would set the RRBP and poll bits on every 8th downlink data block (last three bits of BSN = 0) so that the MS has a chance to acknowledge received / missing blocks in mid-stream rather than waiting until the end. I also set the RRBP and poll bit in the last block. Partly this was so that I had early notification of whether the downlink assignment was successful.

    Early in the message sequence the network sends PDP CNTX ACCEPT and this takes two RLC/MAC data blocks. Both of these have RRBP & poll bits set (the first one because BSN % 8 = 0, the second one because it is the final block).

    I get a PDAN for each block, which is normal, and I get a Channel Request Description which is also normal. When I sent the PUA, though, it is ignored by the MS.

    If I remove the code that adds the mid-flow RRBP and poll bit then it works fine, i.e. I get a PCA for the PUA. If RRBP and poll bits are set on both D/L data blocks then the PUA is ignored.

    Does this make sense? I would expect the PUA to be accepted regardless of how many data blocks have poll bits set.

    #58426 Reply
    Pan2
    Guest

    All,

    if DRX mode is supported in your network. Really Immediate assignment Command on A-bis has no Paging Group info as in Paging command. and in DRX mode an MS is looking for only it’s own paging blocks (and not for AGCH blocks, defined by BS_AG_BLKS_RES).

    How do I send the Immediate assignment Command in a paging group if there is no paging group Info? Could you guys tell me more?

    Pan2

    #58427 Reply
    Pix
    Guest

    Pan2 (are you Pan ?)

    The Immediate assignment command doesn’t need a Paging Group.

    It is sent over the AGCH, not the PCH. If a MS listens to AGCH, it will listen to ALL the AGCH blocks.
    Indeed, a MS on the AGCH is not “idle” anymore. It is setting up a call (either originating the call, or merely replying to a paging that was previously sent on the PCH).

    DRX Mode applies only when the MS is in Idle Mode, listening to the Paging Requests.

    #58428 Reply
    HGL
    Guest

    Recently was activated Extende UL TBF in my NOKIA GSM network. somebody know how to test this feature.

Viewing 14 posts - 1 through 14 (of 14 total)
Reply To: TBF assignment on CCCH
Your information:




<a href="" title="" rel="" target=""> <blockquote cite=""> <code> <pre class=""> <em> <strong> <del datetime="" cite=""> <ins datetime="" cite=""> <ul> <ol start=""> <li> <img src="" border="" alt="" height="" width="">