Nokia Academy RA4140 FL16 Feature Delta Transport and Transmission Features LTE Features
The contents of this document are proprietary and confidential property of Nokia Solutions and Networks. This document is provided subject to confidentiality obligations of the applicable agreement(s). This document is intended for use of Nokia Solutions and Networks customers and collaborators only for the purpose for which this document is submitted by Nokia Solutions and Networks. No part of this document may be reproduced or made available to the public or to any third party in any form or means without the prior written permission of Nokia Solutions and Networks. This document is to be used by properly trained professional personnel. Any use of the contents in this document is limited strictly to the use(s) specifically created in the applicable agreement(s) under which the document is submitted. The user of this document may voluntarily provide suggestions, comments or other feedback to Nokia Solutions and Networks in respect of the contents of this document ("Feedback"). Such Feedback may be used in Nokia Solutions and Networks products and related
specifications or other documentation. Accordingly, if the user of this document gives Nokia Solutions and Networks feedback on the contents of this document, Nokia Solutions and Networks may freely use, disclose, reproduce, license, distribute and otherwise commercialize the feedback in any Nokia Solutions and Networks product, technology, service, specification or other documentation. Nokia Solutions and Networks operates a policy of ongoing development. Nokia Solutions and Networks reserves the right to make changes and improvements to any of the products and/or services described in this document or withdraw this document at any time without prior notice. The contents of this document are provided "as is". Except as required by applicable law, no warranties of any kind, either express or implied, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose, are made in relation to the accuracy, reliability or contents of this document. NOKIA SOLUTIONS AND NETWORKS SHALL NOT BE
RESPONSIBLE IN ANY EVENT FOR ERRORS IN THIS DOCUMENT or for any loss of data or income or any special, incidental, consequential, indirect or direct damages howsoever caused, that might arise from the use of this document or any contents of this document. This document and the product(s) it describes are protected by copyright according to the applicable laws. Nokia is a registered trademark of Nokia Corporation. Other product and company names mentioned herein may be trademarks or trade names of their respective owners. © Nokia Solutions and Networks 2016
•
LTE2184 Flexible Sync Input Priority
•
LTE2299: Dual Stack IPv4/IPv6 for S1/X2
•
LTE2401: Flexible IP Addressing for PKI
Legacy priorities eNB used to be hard-coded to prioritize GNSS, 1PPS and 2.048 MHz sync sources over Transmission sync sources
eNB
1
GNSS/1PPS
2
2.048 MHz
> Only Transmission sync sources used to be user-configurable
Transmission sync sources 1
ToP
high SyncE
3
2
low PDH
New demands
Some deployments demand for more flexibility in prioritization of sync sources > An example is requirement to prefer Timing over Packet over GNSS due to poor GNSS satellite visibility or political reasons against the GNSS usage
New capabilities
The feature LTE2184 Flexible Sync Input Priority allows greater flexibility in prioritization of the sync references
eNB 1 2 3
Ext GNSS
1PPS
Int GNSS
2.048 MHz
highest medium
Transmission sync sources 1
high
2
low
lowest
ToP SyncE PDH
Transmission sync sources
Priorities of transmission sync sources are configured in a separate list that is placed to the core list of sync references as a single joint block >
Transmission sync sources can be prioritized over other sync references, but cannot interleave with core sources.
eNB 1 2 3
Ext GNSS
1PPS
Int GNSS
2.048 MHz
highest medium
Transmission sync sources 1
high
2
low
lowest
ToP SyncE PDH
Platform dependencies and limitations Available sync options depend on specific hardware •
Integrated GNSS applies only to FSIH/FZM It is not supported on FSMF
•
2.048MHz input is not a sync option on FSIH FSIH supports only TDD mode, which requires phase synchronization
•
External GNSS receiver and SyncHub Master are mutually exclusive They connect to the same physical input port
FSMF
FSIH
FZM
1pps/ToD from Sync Hub Master (1)
Yes
Yes
No
1pps/ToD from external GNSS receiver (2)
Yes
Yes
No
internal GNSS receiver (3)
No
Yes
Yes
2.048MHz input (4)
Yes
No
No
transport reference source (5)
Yes
Yes
Yes
Synchronization is obligatory To ensure that the BTS receives valid synchronization, at least one sync reference source must be connected to the BTS and included to the Core Module Sync Input List > Exception: If FDD BTS is operating as a legacy sync slave in RF sharing configuration (SMOD:syncMaster = false), where it receives sync via RP3-01, any entry in the Core Module Sync Input List is ignored, and the list may remain empty.
Enabling bits for sync input features •
Similarly to the list of transmission sync sources, entries in the list of core module sync sources function as feature enabling bits for respective features affecting also corresponding fault and alarm management: -
-
•
Once a sync source is added to the list, its corresponding feature is considered being activated. If a sync source is not added to the list, it is not used for synchronization even if the respective signal presents
Item type in core module sync input list
Legacy feature enabling bit
1pps/ToD from Sync Hub Master (1)
gpsCtrlBlockForCoLocatedBts
1pps/ToD from external GNSS receiver (2)
gpsInuse
internal GNSS receiver (3)
intGpsInuse
2.048MHz input (4)
ext2M048ClkInUse
transport reference source (5)
tdmSyncInUse
Consequently, legacy feature enabling bit parameters are removed from the object model for all sync sources accept ToP-F and ToP-P -
Exception: ToP-F and ToP-P still have independent activation flags and can be activated for testing purposes without being used as synchronization reference.
Priority
Every entry in the list of core module sync sources is assigned a priority from 1 to 3 •
1 denotes the highest priority sync source with priority of 1 is used at the first place, when available
•
3 denotes the lowest priority
eNB 1
highest
2
medium
3
lowest
Sync sources in uncommissioned mode •
Flexible Sync Input is available in commissioned state only
•
In non-commissioned state fixed, default priority table is used The default prioritization in the non-commissioned state is platform-dependent
Priority
FSMF
FSIH
FZM
1
1pps/ToD • external GNSS or • SyncHub Master
1pps/ToD • external GNSS or • SyncHub Master
Integrated GNSS receiver
2
2.048MHz
Integrated GNSS receiver
Transport Synchronization
3
Transport Synchronization
Transport Synchronization
―
Phase offset compensation •
In the legacy implementation phase offset due to signal propagation from a SyncHub Master, external GNSS receiver and internal GNSS receiver used to be compensated with the usage of a single parameter BTSSCL:gpsTotalAntennaLineDelay
•
Because in some deployments the delay can differ among sync sources, the feature replaces the legacy parameter with three independent for each type of a sync input: -
GNNSE:gnssLineDelay (for external GNSS receiver)
-
GNNSI:gnssLineDelay (for internal GNSS receiver)
-
SMOD:totalDelayFromSHM (for 1pps/ToD input from SyncHub Master)
In Phase Synchronization, the are:
options
1.
A Pulse Per Second/Time of Day signal to the port provided from the port of a co-located Flexi BTS.
2.
A Pulse Per Second/Time of Day signal from a Global Navigation Satellite System (GPS or GLONASS) connected to the of this BTS.
3.
A (Timimg over Packet) signal provided through a Transport interface. are configured separately in the Transport settings.
•
•
The LTE2299: Dual Stack IPv4/IPv6 for S1/X2 feature supports simultaneous use of IPv4 and IPv6 for LTE U/Cplane on S1/X2 interfaces (dual stack). The newly-introduced dual-stack-capable eNBs can operate simultaneously in IPv4 and IPv6 over X2 so that dual-stack-capable eNBs can communicate to eNBs independently of whether they run with IPv4 or IPv6. Full dual stack support eases the migration from IPv4-based to IPv6-based networks, enabling S1/X2 connections in all scenarios. -
Dual stack capability for the S1 interface towards MMEs and SGWs. This means that MMEs and S-GWs may have different IP versions in use simultaneously
-
Network architects are able to take full advantage of the X2 interface, irrespective of the IP version used on particular eNBs. Thus, they can have optimized radio neighborship relations without any restrictions to the IP version which are imposed by transport.
-
Network architects get the IPv6-enabled eNBs to support IPv4 X2-based handovers. This is also valid for the legacy FSM2-based neighbor eNBs so that they can use the X2 interface also in cases of an FSM2-installed basis.
•
•
•
•
The LTE2401: Flexible IP Addressing for a PKI feature enables the usage of a dedicated IP address for a public key infrastructure (PKI)/certificate management. This is an additional IP address to the M-plane IP address, which was used alone prior to this feature. The operator is able to establish an Internet Protocol Security (IPsec) tunnel without using the M-plane IP address. With this feature, the eNB allows a different source IP address to be used in the communication with the certificate management protocol (CMP)/Lightweight Directory Access Protocol (LDAP) server. Prior to the LTE2401: Flexible IP Addressing for PKI feature, the BTS used an M -plane IP address for communicating with certificate management protocol (CMP) and certificate revocation list (CRL) servers. To establish an Internet Protocol Security (IPsec) tunnel, certificate retrieval from a certificate authority via CMP/CRL connection is required. In certain network–customer configurations, an eNB cannot reach the CMP/CRL servers if the M-plane IP address is used since the M-plane is supposed to be transported inside an IPsec tunnel. Therefore, it is not possible to retrieve certificate information and establish an IPsec tunnel in these configurations. With this feature, the eNB will allow a different, operator-configured source IP address to be used in all communications with the CMP/CRL servers. When this new address is set to zero, the eNB uses the M-plane IP address as the source IP address in all communications with the CMP/CRL server. Both IPv4 and IPv6 addresses are supported.
