Você está na página 1de 2

In order to activate the URA_PCH It is required to set URA Identities for all th e cells of the RNC before activating

the URA_PCH State (otherwise the activation will fail). have you any idea about how to plan the URA identity for my cells? i know that the value should be a List of 8 maximum elements of Integer in range [0..65535] for each cell ...what else?

My ideas for planning URA_id: 1. Same id - for a cluster of cells, but not for all. Purpose - to reduce the ra te of URA updates. But if clusters are extremely large paging becomes less effic ient: more cells in same URA_ids - more paging signalling broadcasts through all cells of this URA_id - increase in load. 2. Overlapping - i.e. bordering cells must have id-s of both clusters. Purpose to avoid flapping or ping-pong of URA updates. Commonly, 2-3 URA_IDs for one ce ll is enough, howevever - everything is individual - you can have a need of more IDs per cell. All depends on your plan.

how to activate URA_PCH, there are detailed instructions, the vendor E / / /? how to plan URA_PCH? how a signaling to increase the load on the CPU RNC? for my network is already a significant problem. how to increase the paging load ? Please share your experiences thanks

TO plan URA PCH, you can use CELL PCH data as initial, since the procedure is al most the same, in CELL PCH the paging will be based on cell but each time cell r eselection there will be cell update in PS Connected IDLE or PCH. So initially better to map the number of cell updates in CELL PCH and also consi der cell reselection as well, then you define a specific range. SO you will be a ble to see, which area of cells having high cell updates -> its means high mobil ity so it will be high signalling -> this will be merged into 1 URA -> if it is too large you can divide into 2 - 3 URA. This wil reduce the high amount of signalling. but your paging load will increas e but make sure your URA is not soo big

Some networks I know put whole LA into one URA. As number of terminals in URA_PC H is relatively small, there is no big impact on paging. It is other signalling where you save RNC CPU capacity. We monitor number of URA_PCH terminals in LAC/RNC: as soon us paging become an i ssue, we will start splitting. SPlit criteria is simple: minimize mobility between dif ferent URA by selecting URA properly (like mini-LAC) and allocating more URA to cells needi

ng it. Anyhow, having more URA in the cell increase paging. Otherwise, it works fine. Looks like our vendor finally managed to fix all probl ems with old terminals, and tehre are no problems visible to users. (just use fresh enough SW release an d do not worry about wrong stats).

you mentioned that the number of terminals in URA_PCH is relatively small. why you say that? i would think that all UEs which are on a packet call (especia lly all smartphones) at some point they will end-up at the URA_PCH state. to my understanding for a mature networks with lots of always-on UEs, their numb er will be even larger than the number of UEs in idle_mode. cheers

Usually when you have hsdpa/r99 modem or smartphone like blakcberry, iphon, andr o, which always ps connected so the PCH state will be utilized, so the number of PCH states either URA or Cell PCH will be larger. But if you dont activate the HS RRC State, so there will be no PCH state or even FACH, it willl be disconnected at all, and all typical smartphone is always try ing to connect when it is disconnected so this will consume huge signalling when the RRC state is disable.

Relatively small compared to idle terminals. It takes some activity to stay on U RA_PCH.... Very high compared to Videtelephony usage. Anyhow: for me, one URA per LAC is OK today. Paging is not limiting me (with common BSS/UTRAN LA, BSS is paging limit factor).