- This topic has 13 replies, 1 voice, and was last updated 14 years, 2 months ago by HGL.
-
AuthorPosts
-
12th August 2009 at 14:26 #58415CMGuest
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?
12th August 2009 at 18:14 #58416PixGuestHello 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,
Pix12th August 2009 at 23:57 #58417CMGuestHmmm.. 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.
13th August 2009 at 10:12 #58418PanGuestDear, 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.13th August 2009 at 10:31 #58419CMGuestPan,
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…
13th August 2009 at 12:06 #58420PanGuestCM,
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?13th August 2009 at 13:30 #58421CMGuest1. 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.
13th August 2009 at 14:13 #58422PanGuestCM,
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).13th August 2009 at 15:11 #58423CMGuest43.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).
13th August 2009 at 19:27 #58424PanGuestWell, 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.17th August 2009 at 17:17 #58425CMGuestLatest 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.
15th December 2009 at 22:30 #58426Pan2GuestAll,
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
16th December 2009 at 15:56 #58427PixGuestPan2 (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.
24th February 2010 at 23:44 #58428HGLGuestRecently was activated Extende UL TBF in my NOKIA GSM network. somebody know how to test this feature.
-
AuthorPosts
- The forum ‘Telecom Design’ is closed to new topics and replies.