Keith asked a question about the tracking area code (TAC) in LTE cellular measurements at the last meeting. I did some reading on the subject, but the email exchange that I've included below was far more helpful.
As I understand it, each LTE cell is assigned to a tracking area, identified by a TAC. This code is known to devices and it could be used as a coarse substitute for the cell identifier. Other than that, it's not particularly relevant as a measurement parameter, other than as a potential shortcut for identifying a serving MME (if that is at all interesting to you). If you know about the cell id, then it's usually fairly trivial to find the TAC.
There's little harm in adding TAC to the measurement set, but equally marginal gain. I'm inclined to omit it at this stage, though I could easily be convinced to change my mind. Note that this is a different conclusion than was reached for 3GPP 24.229 or SUPL 2.0.
What occupied the rest of the discussion was the physical cell identifier (PCI), an identifier that is used to identify cells locally. Unless a device is actively interacting with a cell, it likely only sees this 9 bit code. In all likelihood, a device is only going to be able to provide a cell id for its serving cell and a PCI for a handful of neighbours. Thus, including PCI in measurements (and other such "colour codes" like PSC for UTRAN or ARFCN/BSIC for GERAN) allows the possessor of a cell database the ability to identify neighbouring cells.
The original intent of the cellular measurement section was to provide the absolute minimum measurement capability for cellular networks. The range of options available for cellular positioning are pretty crazy and starting down that slippery slope didn't sound like a good idea. For instance, adding ARFCN/BSIC means that it's logical to add the rest of a network measurement report, which includes signal strengths.
As above, I'm inclined to add nothing, but would be interested to hear dissenting opinions. It's not so hard to change either way.
--Martin
The below is forwarded with permission.
_____________________________________________
From: Pawson, Darren
Sent: Thursday, 14 April 2011 1:37 PM
To: Thomson, Martin; Tran, Khiem
Subject: RE: TAC and E-CID
Inline...
-----Original Message-----
From: Thomson, Martin
Sent: Thursday, 14 April 2011 12:17 PM
To: Pawson, Darren; Tran, Khiem
Subject: RE: TAC and E-CID
So let me get this straight:
MCC + MNC + EUCID is sufficient to identify an eNodeB.
[DP] Correct
MCC + MNC + EUCID + PCI is needed to identify the physical transmitter.
[DP] Not really, since MCC + MNC + EUCID should basically identify the transmitter. The main point is that for neighbour measurements, we may only get PCI for a neighbour cell, and not the MCC/MNC/EUCID. The PCI will be unique among cells within a given hearability area, but given there are only 512 values obviously they are re-used frequently in other areas of the network.
So, think of it more like the ARFCN/BSIC combo for GSM neighbour reporting. Getting just a PCI, in conjunction with knowing the MCC/MNC/EUID of the serving cell, needs to be enough to get us to the MCC/MNC/EUID in our DB of that particular neighbour cell (whether it be via a provisioned neighbour list on the serving cell or a nice spatial query to look for the PCIs of the cells near the serving cell 8-).
And each MCC + MNC + EUCID is allocated to an MCC + MNC + TAC. MCC + MNC + TAC represents a group of cells, so you can use it for location, but it's not hugely important (other than perhaps helping us identify the MME if we needed to talk to the eNodeB for some reason).
[DP] Correct
If I keyed cells on MCC + MNC + EUCID [ + PCI ], where PCI is optional, would that work? SUPL makes PCI mandatory.
[DP] As discussed above, I don't think you need the PCI within the key.
Just make sure you have a way to get to the MCC + MNC + EUID given only a PCI and the MCC + MNC + EUID of another nearby cell.
For CID measurements, adding an optional additional TAC parameter might be helpful, but it doesn't sound critical. SUPL has it as mandatory though - I suppose that a SET will always be able to measure it, so there's no harm in making it mandatory for measurements.
--Martin
-----Original Message-----
From: Pawson, Darren
Sent: Wednesday, 13 April 2011 2:17 PM
To: Thomson, Martin; Tran, Khiem
Subject: RE: TAC and E-CID
By the way, have you got the PhysicalCellId (PCI) in your cell database? This is the equivalent of the PrimaryScramblingCode (PSC) in UTRAN and is essentially the local colour code of the cell. We'll probably need this for E-CID to identify the reported neighbour cells.
DArren
-----Original Message-----
From: Pawson, Darren
Sent: Wednesday, 13 April 2011 2:14 PM
To: Thomson, Martin; Tran, Khiem
Subject: RE: TAC and E-CID
A TA (Tracking Area) basically serves the same purpose as a Routing Area and Location Area in UMTS/GSM.
That is, it identifies a group of cells to the core network within which the UE is known to be located. There are the usual opposing forces at play of minimising the tracking area so that you don't have to page too many cells for mobile terminated operations, as well as maximising the tracking area so the UE doesn't need to send too many Tracking Area Update messages as it moves around.
Each cell will have a tracking area code, but I guess the question you are asking is do we really need it for any purpose in positioning?
We shouldn't need it for any CellID, E-CID or A-GPS operations (or any other method that utilises connection-oriented messaging on SLs). The only thing I can think of why we may potentially need it is for OTDOA (or any other connectionless messaging to an eNB). In order to communicate using LPPa to an eNB outside of an active location session, we need to identify which MME to send the LCS-AP message to. We can basically use any MME that has a signalling relationship to the eNB. Knowing the TAC of the eNB we want to talk to may allow us to choose the MME.
Darren
-----Original Message-----
From: Thomson, Martin
Sent: Wednesday, 13 April 2011 12:08 PM
To: Pawson, Darren; Tran, Khiem
Subject: TAC and E-CID
Can either of you explain the role of the TAC in identifying a cell in the E-UTRAN? Someone pointed out that we'd omitted this in our cell identifiers. Is it useful/necessary?
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
