TSGS5#5 (99) 142: Münster, GERMANY, 29-30 June 1999
TSGS5#5 (99) 142: Münster, GERMANY, 29-30 June 1999
TSGS5#5 (99) 142: Münster, GERMANY, 29-30 June 1999
TSGS5#5(99)142
TSGR3#5(99) 606
Introduction
At the RAN-WG3 meeting #4 O&M adhoc session, a question arose as to which network element, the CRNC or the Node B, would be the owner of the logical cell parameters. After debate, a working assumption was established which states any parameter configuration relating to the logical cell model as defined by RANWG3 should be performed within the CRNC. The CRNC will then control the configuration of these logical cell parameters at Node B via the Iub interface (reference: tdoc-572). It will be shown below that the working assumption for CRNC control of logical cell parameters should not apply to all parameters. Node B control of certain logical cell parameters is needed to help facilitate RNC Node B multi-vendor interoperability. It is the intention of this contribution to do the following: 1. To start a list of logical cell parameters needed for the definition of a cell. Note that this list may not be exhaustive. 2. To indicate whether the value of the logical cell parameter is actively used or must be known by the CRNC, the Node B, or (shared) by both the CRNC and Node B for cell operation and / or control. 3. To indicate the owner of each logical cell parameter. The owner of the parameter is the network element where the value should be configured via the management system or defaulted within the network element itself. The parameter owner communicates the value to the other network element via an NBAP procedure (not specified in this contribution). For some parameters, there is no clear owner; thus ownership can be arbitrarily assigned to the CRNC or Node B.
Discussion
Description of table columns:
Cell Parameters Description CRNC Reqd. Node B Reqd. Per Cell / Per Carrier Owner Reason Textual name of the cell parameter Description of the purpose of the cell parameter Indicates whether this parameter needs to be known / used by the CRNC Indicates whether this parameter needs to be known / used by the Node B Indicates whether this parameter can be applicable on a per carrier per cell basis, in addition to just a per cell basis Network element (NE) where the parameter should be configured via the management system or defaulted within the NE Where applicable, justification for NE ownership
TSGS5#5(99)142
Per Carrier / Per Cell X X X Owner Node B Node B Node B CRNC Reason See NOTE 1 See NOTE 2 See NOTE 2
BCH Data Gain BCH Pilot Gain FACH Code FACH Data Gain FACH Pilot Gain FACH Transmit Offset PCH Code PCH Data Gain PCH Pilot Gain PCH Transmit Offset DSCH Code DSCH Data Gain DSCH Pilot Gain DSCH Transmit Offset SCH Gain PRACH Spreading Factor PRACH Preamble signature PRACH Window Detection Range PRACH Spreading Code RACH Control Parameters
X X X X X X X X
X X X
X X X X
X X X X
X X X X X X X X X
See NOTE 3
TSGS5#5(99)142
Per Carrier / Per Cell Owner Reason
Pilot Add threshold Pilot Drop threshold Downlink Power Control Parameters Uplink Power Control Parameters Rake Configuration Parameters Cell Range Parameters T Cell
CRNC
Node B
Node B
CRNC
NOTE 1: (Node B Gain) The CRNC needs to understand Node B power to perform admission control. The implementation of the PA is vendor specific and thus may have limitations and restrictions beyond what the RNC, and the management model for the RNC, should be expected to understand. NOTE 2: (Forward Frequency and Reverse Frequency) There are two issues in regards to assigning frequency parameters: Issue 1 the time to tune to a frequency will vary for each vendors Node B. If the CRNC is assumed to own the frequency parameters, then there is no set time for CRNC to know if the frequency allocation was successful at the Node B. It is better for the Node B to own the frequency parameters and to notify the CRNC when the Node B has finished applying its logical parameter set. Issue 2 vendor specific hardware implementation may limit the frequencies usable. Support for this limitation should be in the Node B management system and hence the Node B should own the parameters. Any potential physical limitations associated with a parameter at a NE should result in that NE owning that parameter. NOTE 3: The Node B should own the parameters because it is the Node B that is aware of the power capability of the cell. Do not expect these parameters to be changed dynamically, but rather by O&M applications.
Proposal
1. To change the RAN-WG3 current working assumption stated in I3.05 section 4.2 that configuration of parameters in the logical cell model is performed within the CRNC, which then controls the configuration of the logical cell parameters for the Node B. The working assumption should state that a division of the
TSGS5#5(99)142
logical cell parameters is required, where ownership of each logical cell parameter is given to the NE where it makes the most sense (e.g., where hardware dependencies exist, etc).