Archive for the ‘Technical Notes’ Category

GPRS Dual Transfer Mode

They say necessity is the mother of invention. So when GPRS saw the upcoming competition from UMTS it had to invent new methods to keep itself alive longer in the cellular world. The greater truth is that everyone knew that UMTS will not replace GSM/GPRS overnight. Rather, these two access standards will co-exist for a long time to come before 3G completely replaces 2.5G. More than competition, it was completion and cooperation.

It was correctly envisaged that this coexistence will happen for the following reasons:

  1. Going by demand, deployment of 3G cells will happen in phases whereby urban areas could be covered by 3G while rural areas continue on 2.5G. This means that movement from urban to rural will trigger an inter-RAT handover.
  2. 3G may be deployed at the level of microcells while at the macrocell level 2.5G may be used.
  3. Operators have invested considerably in 2.5G and the move to 3G will at best be a transition.
  4. Because WCDMA at 2100 MHz generally lacks the indoor coverage that’s possible with GSM 900 MHz, this leads to another use case for inter-RAT handover.
  5. It will take time for users to switch consumption patterns, to move from voice-centric to data-centric.
  6. It will take time for users to give up their old handsets in favour of 3G-enabled handsets.

Whatever be the case, one of the keys problems for GPRS is that CS and PS traffic cannot happen simultaneously. How then can we meet user expectations when an inter-RAT handover from UMTS to GPRS will necessarily mean dropping the packet connection?

GPRS standards provides for three classes of MS:

  • Class A: supports simultaneous attach, simultaneous activation, simultaneous monitor, simultaneous invocation and simultaneous traffic. A CS call in the middle of PS call will not disrupt the latter. This class of a mobile may even require two transceivers because CS and PS could be on different frequencies. RF duplexers may be needed along with multiple call processing units. There is no coordination between the two service domains. As such, such a mobile is quite complex and rarely implemented. The cost of such a mobile is also likely to be high and with possibly low battery life.
  • Class B: supports simultaneous attach, simultaneous activation and simultaneous monitor. Service invocation and traffic are mutually exclusive. This means that a CS call in the midst of a PS call will suspend the latter.
  • Class C: the two domains are mutually exclusive even for attach. If MS is used for the CS domain (possibly chosen by the user), PS domain becomes unavailable.

Thus, although the class A mobile will suit inter-RAT handover from UTRAN, it is prohibitively complex. To overcome this problem, designers have standardized the Class A Dual Transfer Mode (DTM) MS which can be seen as a subset of a Class A MS. This work started in November 1999. Today it is fairly stable and we are beginning to see DTM mobiles in the market [1]. Its characteristics are the following:

  1. Simultaneous traffic on both domains is possible and network coordinates this. Thus, the domains are not independent as a true Class A MS. Changes in the network are necessary to enable this coordination. In particular, the BSS maintains a mapping of the IMSI and TLLI. This enables the BSS to “page” a mobile (using PACCH) in Packet Transfer Mode for an incoming CS call. Thus, even without a Gs interface, such paging coordination is possible. This is a new network mode known as NMO-II bis.
  2. While it is true that a CS call can be added to an MS in Packet Transfer Mode, this happens in three stages. TBF is released. A dedicated connection is initiated. Finally, the MS transits to DTM for re-establishing the data connection. The state transitions are depicted in Figure 1.
  3. Resources assignments towards DTM state are made using one of three messages: DTM Assignment Command (generally used when CS resources have to be reallocated), Packet Assignment Command (when only PS resources have to be added while keeping CS resources the same), Main DCCH Assignment (for single timeslot packet signalling on main DCCH).
  4. CS and PS are carried on the same frequency. The use of timeslots is also restricted. Both calls could be shared on a single slot. In this case, both are half-rate channels (TCH/H + PDTCH/H). To clarify, although an RLC/MAC block is sent in four bursts, at half rate it is physically sent over 8 TDMA frames. If multislots are used, the slots have to be contiguous (TCH + multiple PDTCH). Although multislot approach gives higher data rates, in the event of a handover, it will be difficult to find just as many empty slots in the target cell.
  5. To simplify signalling procedures, main DCCH can be used for packet procedures. Thus, an MS is dedicated mode can be paged for a packet call using the main DCCH. Likewise, the MS can request to perform Cell Update or Routing Area Update during a CS call using the main DCCH.
  6. Use of main DCCH for PS signalling is on SAPI 0. For the purpose of demultiplexing, a new protocol discriminator (PD) has been defined – GPRS Transparent Transport Protocol (GTTP). All messages with this PD are passed transparently by the BSS to the SGSN. This reduced the congestion caused by GPRS signalling that happens on the border of RA/LA.
  7. The use of main DCCH for PS domain signalling may affect the signalling of an active CS call. As an alternative, new allocations using DTM procedures can be used. These may reallocate resources of the ongoing CS call.
  8. Certain things can be coordinated between the two domains – measurements, timing advance, power control.
  9. An MS in DTM, can be commanded by the BSS to make a handover. MS will not perform any cell reselection and NC mode does not matter.
  10. An MS supporting a certain multislot class will support all lower classes as well.
  11. While a non-DTM MS will support dynamic allocation and fixed allocation, a DTM mobile can have exclusive allocation in the uplink as an extra.
  12. It will be clear from Figure 1, that a dedicated connection cannot be released while maintaining the TBF. Thus, PS call will be temporarily suspended before it is again established. However, there is an enhanced CS release procedure by which the MS may be sent SI/PSI to ease re-entry into Packet Transfer Mode. PSI 14 has been defined for this purpose which may received in DTM state. Packet CS Release Indication (on PACCH), Packet SI Status, Packet PSI Status and Packet Serving Cell Data (PSCD) are also used in this regard.

Figure 1: RR Operating Modes and State Transitions

DTM States

From my search on the Internet, I discovered that one common class implemented by mobile phone vendors is the DTM Multislot Class 11. The technical specification of Nokia N95 states a speed of DL/UL 177.6/118.4 kbps. Given that Multislot Class 11 represents 4 Rx, 3 Tx and 5 active slots per frame, it is not clear how these data rates have been obtained.

Overall, DTM is a significant feature for a GPRS phone. Its has great value within a dual-mode phone. Users may notice slower data rates following a handover from UTRAN, but at least they will not lose their data connection; nor will they get into a habit of terminating their voice calls to get their important data through. Eventually, DTM will not be required as we move to an all-IP core and the inevitable death of CS domain. In the meantime while we have it, we need to ask one question: How often do we download/upload data while on a voice call?


  1. List of S60 devices supporting GPRS Class A (Dual Transfer Mode), Nokia Forum, 27 Sept 2007.
  2. Mark Pecen and Andrew Howell, Simultaneous Voice and Data Operation for GPRS/EDGE: Class A Dual Transfer Mode, IEEE Personal Communications, April 2001.

Read Full Post »

Identities of a Dual-Mode Phone

This post is not meant to be comprehensive but I shall attempt to cover the most important identities used to identify the UE/MS. It has been a difficult task the reason being that information is spread across many specifications. If there are errors, do let me know. I also appreciate assistance on making this list complete.

Identities are summarized in Table 1. Shaded cells refer to group identities. Many of these identities can exist at the same time. Some identities are mutually exclusive. For example, TLLI cannot exist at the same time as C-RNTI. The former’s context is with the GPRS CN and the latter’s is within UTRAN.

An RNTI (Radio Network Temporary Identifier) exists only when the UE has an RRC connection. Depending upon the context and allocator, different RNTIs exist as listed in Table 1. RNTIs are deallocated when RRC connection is released.

Table 1: UE/MS Identities








Cell Radio Network Temporary Identifier

  • Allocated by the CRNC.
  • Unique within the cell controlled by the CRNC.
  • Can be reallocated when UE changes cell with a Cell Update procedure.
  • Deallocated when RRC connection is released
  • Used by MAC to address a UE-UTRAN connection when DCCH/DTCH are mapped to common transport channels.
  • Can be used by MAC on UL and DL transport channels.




Downlink Shared Channel Radio Network Temporary Identifier

  • Used only for TDD.
  • Used on the SHCCH.




E-DCH Radio Network Temporary Identifier

  • For E-DCH (HSUPA) only.
  • Two variants are possible: primary and secondary: both can be active at the same time.
  • RRC signalling configures the UE to use either primary or secondary.
  • Identity is used by PHY to address the UE on E-AGCH. Identity is used as a mask on the 16-bit CRC.




GERAN Radio Network Temporary Identifier

  • Applicable from Release 5 onwards for GERAN Iu Mode.
  • Allocated by RRC in the Serving BSC and unique within the BSC.
  • Reallocated when the SBSC changes
  • Used at RLC/MAC during contention resolution. If there is no allocation, a random G-RNTI is used; otherwise the allocated identity is used.
  • Deallocated when RRC connection is released.
  • Derived from TLLI codespace. Used on Iu interface and quite similar in purpose to TLLI used on A/Gb.



HS-DSCH Ratio Network Temporary Identifier

  • For HSDPA only.
  • Identity is used by PHY to address the UE on HS-SCCH. Identity is used as a mask on the 16-bit CRC.




International Mobile Station Equipment Identity

  • Unique number allocated to each Mobile Equipment (ME) in the PLMN.
  • Unconditionally implemented by the MS manufacturer.
  • Generally used to block stolen mobiles. IMEI can be changed but it is illegal in some countries (UK for example).
  • Composed of Type Allocation Code (TAC) + Serial Number (SNR) + spare digit = 8 + 6 + 1= 15 digits.
  • IMEI will be used for emergency call establishment and re-establishment only when SIM/USIM and IMSI are not available.




International Mobile Station Equipment Identity with Software Version Number

  • Similar to IMEI; composed of Type Allocation Code (TAC) + Serial Number (SNR) + Software Version Number (SVN) = 8 + 6 + 2= 16 digits.
  • Optionally included by the mobile in Authentication and Ciphering Response.




International mobile group identity





IP Multimedia Private Identity

  • Used in IMS.
  • Could be based on IMSI if not allocated explicitly.
  • Of the form “user@domain”.




IP Multimedia Public identity

  • Used in IMS.
  • Of the form “sip:user@domain”.




International Mobile Subscriber Identity

  • Variants exist based on the type of CN: IMSI-DS-41, IMSI-GSM-MAP, IMSI-and-ESN-DS-41. Here we are refer to IMSI-GSM-MAP when we say IMSI.
  • Allocated to each mobile subscriber in the GSM/UMTS system.
  • ITU-T refers to this as International Mobile Station Identity.
  • This is the common identity across both CN domains.
  • RAN uses it for coordination with UE. CN transfers identity to RAN using RANAP. RAN deletes it when RRC connection is released.
  • Consists of MCC (3 digits) + MNC (2 or 3 digits) + MSIN.
  • Used by RRC for CN originated paging.
  • Generally avoided on the air interface in lieu of TMSI or P-TMSI unless the latter is not recognized by the CN or not available at the mobile.
<= 15



International Mobile User Number

  • A diallable number allocated to a 3GPP System user.
  • Not sure how this is used.




International USIM Identifier





Local Mobile Station Identity

  • Allocated by the VLR and mapped to IMSI.
  • Used for communication with HLR although HLR makes no use of it. HLR merely sends it back in its responses.
  • Facilitates easy search of database at the VLR.
  • Advantage is that TMSI could be reallocated while LMSI is persistent.




Mobile Station Identifier





Mobile Station Identification Number

  • Part of IMSI.
  • Identifies the mobile within the PLMN.
  • The leading digits may in some cases used by the PLMN to identify quickly the HLR.
  • If MNC has just 2 digits, this identity has a leading zero.

<= 10



Mobile Station/Subscriber ISDN Number

  • Number by which the mobile can be called.
  • Composed of Country Code (CC) + National Destination Code (NDC) + Subscriber Number (SN).
  • An NDC is required for each PLMN. Some PLMNs may require more than one NDC.
  • Parts of the identity are used by SCCP for routing messages to the HLR.




Mobile Station Roaming Number

  • Allocated by the VLR.
  • Used to route calls to the mobile.
  • Passed by the HLR to GMSC for routing purpose.
  • Identity addresses the MSC/VLR where the mobile currently has a context.
  • Has a structure similar to MSISDN.
  • A mobile may have more than one MSRN.




Mobile User Identifier





National Mobile Station Identifier

  • Part of IMSI.
  • Composed of MNC + MSIN.
  • Managed within relevant national bodies.

<= 12



National User / USIM Identifier

Network User Identification





Packet Temporary Mobile Subscriber Identity

  • Variants exist based on the type of CN: P-TMSI-GSM-MAP, P-TMSI-and-RAI-GSM-MAP. Here we refer to P-TMSI-GSM-MAP when we say P-TMSI.
  • Used instead of IMSI to implement subscriber confidentiality in the PS domain.
  • Allocated by SGSN which maps it to the IMSI.
  • Extensively used by GMM.
  • Generally reallocated when Routing Area changes. Has local context within a RA, outside which it has to be combined with RAI.
  • Used by RRC for CN originated paging. If it exists, preferred over IMSI for packet paging.
  • A P-TMSI signature exists to enable GMM establish the context of a mobile.




SRNC Radio Network Temporary Identifier

  • Allocated by the SRNC and unique within the SRNC.
  • Reallocated during SRNC Relocation.
  • Deallocated when RRC connection is released.
  • A shorted version (10 bits) exists for signalling purpose only during a handover to UTRAN.




Temporary Logical Link Identity

  • Used on the GPRS air interface (RLC/MAC) to address the mobile.
  • Allocated by the MS based on P-TMSI (local or foreign TLLI) or directly (random TLLI).
  • Auxiliary TLLI is allocated by the SGSN but this is no longer required from R99 onwards.
  • Part of the TLLI codespace is reserved for G-RNTI.
  • Used by LLC in SGSN to uniquely identify the MS.
  • TLLI along with NSAPI is used by SGSN to identify the PDP context to which a packet belongs.




Temporary Mobile Group Identity

  • Used to identify an MBMS Bearer Service.
  • Allocated by BM-SC.
  • Used for either broadcast or multicast service.
  • This is the radio resource equivalent of MBMS Bearer Service Identification consisting of IP multicast address and APN.
  • Contains 24 bits of MBMS Service Id and optionally MCC (12 bits) MNC (12 bits) if the session is from a non-local PLMN.
  • Identity is used by RR/GRR for packet paging procedures for MBMS (pre-)notification. An optional MBMS Session Identity is used along with TMGI if notification is done on A/Gb mode.
  • Identity used by Layer 3.

24, 48



Temporary Mobile Subscriber Identity

  • Variants exist based on the type of CN: TMSI-DS-41, TMSI-GSM-MAP, TMSI-and-LAI-GSM-MAP. Here we are refer to TMSI-GSM-MAP when we say TMSI.
  • Used instead of IMSI to implement subscriber confidentiality in the CS domain.
  • Allocated by VLR which maps it to the IMSI.
  • Extensively used by MM.
  • Generally reallocated when Location Area changes. Has local context within an LA, outside which it has to be combined with LAI.
  • Used by RRC for CN originated paging.
  • Format of TMSI is not standardized.




UTRAN Radio Network Temporary Identifier

  • Identifies the UE uniquely within UTRAN.
  • Made of two parts: SRNC identifier (12 bits) + S-RNTI (20 bits).
  • Used to identify UE in many RRC procedures in CELL_FACH (Cell Update, URA Update, UTRAN Originated Paging).
  • Used by MAC to address a UE-UTRAN connection when DCCH/DTCH are mapped to common transport channels.
  • Not used by MAC in the UL but can be used by RRC. Used by MAC only in the DL when DCCH is mapped to FACH for SRB1 (alternative is the C-RNTI).
  • During a handover to UTRAN, RRC signalling uses U-RNTI-Short in which the S-RNTI component has only 10 bits. The shortened S-RNTI is expanded to 20 bits to (MSBs set to zeros) and the final U-RNTI is generated.
  • Rel5 RRC signalling uses this in a modified form to address a group of UEs for RRC connection release.



Some identities need explanation. Since C-RNTI and U-RNTI are usually meant for use in CELL_FACH states, it may be puzzling to note that these can be reallocated in CELL_DCH state. Such a reallocation will generally happen in the case of handovers when the CRNC or SRNC change. The UE will merely store the identities until a later time when they may be required. For example, after the handover the channel conditions may worsen triggering a Cell Update procedure on CCCH. This procedure will then make use of the U-RNTI within RRC Cell Update message. The Cell Update Confirm may be on CCCH or on DCCH. In the former case, the U-RNTI will be returned within the message. In the latter case, U-RNTI is used at MAC. Either way, Cell Update Confirm may in its turn allocate new identities.

Specifications [TS 24.008] define the conditions under which the mobile shall use IMEI, IMSI, TMSI or P-TMSI. Some of these have been mentioned in Table 1. Specification titled “Numbering, addressing and identification” [TS 23.003] is a good source of information. The use of some of these identities by RR/GRR/RRC can be found in relevant specifications [TS 44.018, TS 44.060, TS 44.160, TS 25.331]. The use of E-RNTI and H-RNTI is mentioned in a PHY layer specification [TS 25.212]. Some details on TMGI is in an MBMS specification [TS 23.246].

Other important identities for the mobile are DLCI, XID, NSAPI and TI. Because these pertain more to connections at a specific layer rather than the MS/UE as a whole, they have been left out of this discussion.



Read Full Post »

Following the article on GPRS cell reselection and NACC, I thought it was appropriate to mention neighbouring cells that the MS monitors. The list of neighbour cells is formed by a complex process in which information is gathered from different sources. As an easy reference, this post attempts to summarize this process. This post will look at:

  • GSM Neighbour Cell List for GSM
  • GSM Neighbour Cell List for GPRS

The term “GSM Neighbour Cell List” is so named to distinguish it from 3G Neighbour Cell List. It is applicable to GPRS as well. It is simply a list of neighbours that the MS maintains. It makes measurements on these cells and reports them to the network if configured to do so. Cell reselection depends on these measurements.

The final list that the MS maintains is the Neighbour Cell List which is a concatenation of GSM Neighbour Cell List and 3G Neighbour Cell List. For the purpose of reporting measurements, the lists are treated separately.

Every cell maintains a BCCH Allocation List or BA List which is a list of frequencies of neighbouring cells. This information is useful for the MS for performing and reporting measurements, and eventually in cell reselection and handover. The BA List is formed from information in the SI. For GPRS, BA(GPRS) exists which is formed from information in PSI. If the cell does not have a PBCCH, BA(GPRS) equates to BA(list) obtained from SI. The key difference between BA(list) and BA(GPRS) is that the former is only a frequency list and the latter is a list of frequencies paired with Base Station Identification Code (BSIC). BSIC allows for cell changes across cells that are not necessarily neighbours in a geographic sense. So an MS could do a cell reselection across cells with the same frequency but different BSIC. Such a possibility arises if the immediate neighbours are hidden (no line of sight) whereas a far away cell can provide better service due to clear LOS radio path.

Figure 1: GSM NC List (GSM)

Now let us look at the formation of GSM Neighbour Cell List for GSM (Figure 1). In idle mode, BA(list) is formed from SI2/2bis/2ter while in dedicated mode SI5/5bis/5ter are used. If the latter set is missing completely in dedicated mode, the former will be used. SI2quater enhances the BA(list) by providing BSICs. The combination of the two makes the GSM NC List. SI2quater was introduced for enhanced measurements, a feature I will describe in a separate post. In dedicated mode, Measurement Information (MI) is used instead of SI2quater but the end result is the same as in idle mode. If SI5 and MI are both not sent to the MS in dedicated mode, the GSM NC List in dedicated mode is same as in idle mode.

Figure 2: GSM NC List (GPRS)

Figure 2 illustrates the formation of GSM NC List for GPRS. In packet idle mode without PBCCH on the cell, the BA(GPRS) is only a frequency list. Combined with BSIC information in SI2quater this becomes the GSM NC List. If PBCCH is present, PSI3/3bis is used to make the BA(GPRS) which contains pairs of frequency and BSIC. This is also the GSM NC List. In packet transfer mode, the GSM NC List formed in packet idle mode is reused. Elements of this list can be deleted or new elements can be added using Packet Measurement Order (PMO) or Packet Cell Change Order (PCCO). Addition happens on the GSM NC List and is based on pairing of frequency and BSIC. Deletion happens on the BA(GPRS) and is based on frequency which implies that all cells with that frequency are removed from the GSM NC List regardless of the BSIC. Such a definition is useful if the BA(GPRS) is only a frequency list as in a cell without PBCCH.

Among the cells in the GSM NC List for GPRS, some may be cells with both Iu and A/Gb modes. There may be cells with only Iu mode. In the final count, the list can have a maximum of 96 cells and 32 unique frequencies.

Read Full Post »

In a cellular system, it is common for mobiles to move from cell to cell while an active data connection is in progress. In GPRS, this happens with a cell reselection during which there is a short break in communication. This is called service outage and is defined as [TR 44.901],

the time between the last received uplink RLC block from the mobile station in the old cell and the mobile station’s first uplink RLC block received in the new cell.

Service outage dampens user experience. It can be of the order of a few seconds, certainly a bad thing for real-time or streaming services. GPRS has been designed in such a way that many parameters that control communication with a particular mobile are optional. If these optional parameters are absent during the setup phase of a TBF (Temporary Block Flow), equivalent parameters from SI/PSI are used. This means that an MS that does cell reselection must first acquire a defined minimum set of SI/PSI in the target cell before resuming the TBF in the new cell. This contributes to the long service outage.

An equivalent problem in UMTS does not exist or has been mitigated by sensible design. In UMTS, the UE does handover (hard or soft) when RRC is in CELL_DCH. This is the common case. Occasionally, when RRC is in CELL_FACH with an active connection on PS domain, the UE does cell reselection. However, CELL_FACH allows the mobile to acquire SIBs of neighbour cells before cell reselection is triggered. The problem in UTRAN occurs only if the chosen cell for reselection is of a different frequency. Service outage within UTRAN is less but is still a problem when UTRAN-GERAN cell reselection is triggered.

Network Assisted Cell Change (NACC) was introduced in Release 4 to mitigate this problem. Network assists the MS so that it has necessary SI/PSI of the target cell in advance of the cell reselection. Service outage is reduced from the order of a few seconds to 300 – 700 ms [TR 44.901] . NACC has two main procedures:

  • One part that can assist an MS in packet transfer mode with neighbour cell system information required for initial packet access after a cell change.
  • One part in which the mobile station notifies the network when the cell change criteria is fulfilled and delays the cell re-selection a short time to let the network respond with neighbour cell system information (CCN mode procedures).

The need for two variants can be understood by the NC modes which controls GPRS cell reselection. There are three NC modes: NC0, NC1 and NC2. In the case of NC0 and NC1 MS does reselection autonomously. In these two modes, the MS enters the CCN (Cell Change Notification) mode which is new for NACC. The MS indicates to the network that it has chosen a cell for reselection but delays the procedure by entering CCN mode. This gives the network time to send SI/PSI of the selected neighbour cell. In NC1 and NC2 MS sends measurement reports to the network, which can then initiate a cell reselection process. Before such an initiation, the network sends SI/PSI to the MS.

NACC adds the possibility to let the MS operate in NC0 and reduces the loading on the signalling in terms of measurement reporting. Even in NC0, the use of NACC enables the network to direct the MS to select a cell that could be different from the one chosen by the MS.

Another important detail is that the MS delays the cell reselection until complete RLC SDU has been transferred. This is only best-effort. If the connection to the current cell is really bad to make further transfer impossible, the MS has to quickly move to the target cell.

The following RLC/MAC messages have been added to enable NACC:

  • Packet Cell Change Notification (PCCN): MS indicates to network that it wants to move to another cell and enters CCN mode
  • Packet Cell Change Continue (PCCC): network asks MS to continue with cell reselection after sending necessary SI/PSI of neighbour cell
  • Packet Neighbour Cell Data (PNCD): contains SI/PSI or neighbour cell
  • Packet Serving Cell Data (PSCD): contains SI/PSI of current/serving cell: this is useful if only a minimum set has been sent before cell reselection and the rest is sent in this message after cell reselection
  • Packet SI Status: contains SI of current cell: purpose is similar to PSCD
  • Packet PSI Status: contains PSI of current cell: purpose is similar to PSCD

A typical scenario is described in Figure 1. The MS in packet transfer mode determines that a new cell (N1) is to be selected. It delays the reselection and sends PCCN to the serving cell indicating its selection. The serving cell contains the system information of the selected cell N1. Therefore it sends PNCD messages to the MS. Once the required PNCD messages have been sent and once complete RLC SDUs have been transferred, the BSC sends PCCC message. MS switches to the new cell and immediately performs uplink access to restart the TBF. Subsequently, the MS requests the new cell to send the missing system information messages on the PACCH. These are sent to the MS. Some messages may be encapsulated into PSCD messages.

Figure 1: Typical Message Sequence for NACC
NACC Typical Sequence

Figure 1 points to a key fact: “BSC Serving Cell” need not be the same as “BSC Cell N1”. However, in Release 4 the source and target cells must be part of the same BSC. The reason is simple. Unlike UTRAN, in which Iur interfaces one RNC to another, BSCs in BSS are not connected to each other. Thus, SI/PSI of one cell cannot be sent on another cell that’s under a different BSC. Future releases of the specifications extends NACC in many ways:

  • NACC for Geran Iu mode
  • NACC across different BSC

These enhancements are not really mature in the specifications at this point. In other words, it is not clear if CN should be involved in transferring SI/PSI or would it be sufficient to use the Iur-g interface. Should SI/PSI be stored in the SRNC or in the DRNC? Should O&M be involved in storing SI/PSI statically in each CRNC? However, UTRAN RRC [TS 25.331, Rel5] already has updates for NACC for Cell Change Order From UTRAN procedure. Once these are in place and the parameters tuned by study, we can expect smoother data transfer when cell change occurs between UTRAN and GERAN.

Read Full Post »

« Newer Posts - Older Posts »