This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
This material is protected by the copyright and trade secret laws of France and othercountries. It may not be reproduced, distributed, or altered in any fashion by any entity(either internal or external to Alcatel-Lucent), except in accordance with applicableagreements, contracts or licensing, without the express written consent of the W-CDMAPortfolio Management Team and the business management owner of the material.
About Alcatel-Lucent
Alcatel-Lucent provides solutions that enable service providers, enterprises andgovernments worldwide, to deliver voice, data and video communication services to end-users. As a leader in fixed, mobile and converged broadband networking, IP technologies,
applications, and services, Alcatel-Lucent offers the end-to-end solutions that enablecompelling communications services for people at home, at work and on themove. Alcatel-Lucent is a local partner with global reach. The company has the mostexperienced global services team in the industry, and one of the largest research,technology and innovation organizations in the telecommunications industry. For moreinformation on Alcatel-Lucent, visit its web site at: http://www.alcatel-lucent.com.
Notice
At the time of publication, this document reflects the latest information on the Alcatel-Lucent’s Small Cell BSR Cluster Release 4.1 offering. This document will be updated eachtime a new set of features becomes generally available.
Trademarks
All trademarks and service marks specified herein are owned by their respectivecompanies.
1.2 AUDIENCE FOR THIS DOCUMENT ........................................................................... 7 2 RELATED DOCUMENTS .................................................................................... 8
3.9 MANDATORY ACCEPTANCE CRITERIA FOR ROLL OUT .....................................................27
OPERATOR’S BACKHAUL NEEDS TO MEET OUR BACKHAUL REQUIREMENTS (NO EXCEPTIONS) SEE SECTION 4.2. ..............................................................................................27
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 5
OPERATORS’ NETWORK NEEDS TO BE ON RIGHT BCR RELEASE (MINIMUM BCR 3.03) AND ONLY
V2.X OR HIGHER CPE RUNNING ON BCR 3.03 OR LATER SW CAN BE USED. ............................27
OPERATOR NEEDS TO AGREE THE LIMITATIONS AND WHAT IS NOT SUPPORTED SEE SECTIONS
4.3 AND 4.4. ...................................................................................................27
CERTIFICATION TESTS NEEDS TO BE SUCCESSFULLY PASSED. .......................................27
IF ALL CONDITIONS MET SUCCESSFULLY ROLL-OUT CAN START. ...........................................27 3.10 BACKHAUL REQUIREMENTS (HIGH LEVEL VIEW) .......................................................27
V2.X OR HIGHER CPE HARDWARE RUNNING ON BCR 3.0.3 OR LATER SOFTWARE NEEDED. ......28
M AXIMUM ONE FEMTO PER LINK/MODEM. NO SHARING OF SINGLE LINK BY MULTIPLE FEMTOS. ...28
FEMTO OVER SATELLITE BACKHAUL WILL ONLY SUPPORT FIXED LOCATION DEPLOYMENTS E.G. CELL IN A VILLAGE, RURAL AREA. .............................................................................28
CLASS OF SERVICE (COS) BASED QUEUING HAS TO BE CONFIGURED IN THE SATELLITE
4.1.2 Impact of Frequency Change ................................................................29
4.1.3 How to do this via MIM .......................................................................29
4.1.4 How to verify current CPU Frequency .....................................................30
4.1.5 How to enforce 600Mhz CPU frequency ...................................................30
4.1.6 How to revert back to 700Mhz from 600Mhz CPU frequency ..........................30 4.1.7 How to enforce 600Mhz on a specific unit ................................................30
4.3 FMS RADIUS PASSWORD SERVER CONFIGURATION .......................................................32
4.3.1 How To Enable this Feature .................................................................32
4.3.2 Nominal Case Scenario ........................................................................32
4.3.3 Which Condition It Should Fail ..............................................................33 4.3.4 How To Configure WMS-For-Small Cell Server To Allow WIPS Access Even If RADIUSWas Setup For Small Cells ...............................................................................33
4.4 MODIFY FEMTO SERIAL NUMBER .........................................................................34
4.5 EDCH 2MS TO BE USED IN DEMOS ONLY ..................................................................35
See section 3.7.2 “Features with limitations” ......................................................35
4.6 MACRO TO FEMTO HAND OVER BEHAVIOUR ..............................................................35
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 10
3 SMALL CELL BCR4.3 DELIVERY
3.1 Load Highlights
This load is the main BCR4.3.1 load for FOA activities. This is a minor release update tothe main BCR4.3 FOA load delivering CR fixes, restriction removal and minor featurecontent
3.2 Load line up
The BCR4.3.1 load consists of the following equipment and associated software release.
The table below shows all the equipment for the ALU solution; some equipment is
optional per customer implementation.
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
SunOS 5.10 under Solaris 10 with version Generic_127111-09
ALSMS-OS-Solaris-Jun-2010-01
Linux Platform:
OS Requirements for existing installs: RHEL 5 32-bit Linux
ALSMS-OS-RHEL-Oct-2011-v01 Patch +
ALSMS-OS-RHEL-Oct-2011-v02 Patch +
ALSMS-OS-RHEL-Mar-2012-v01 Patch +
ALSMS-OS-RHEL-Jun-2012-v01 Patch +
ALSMS-OS-RHEL-Nov-2012-v01 Patch +
ALSMS-OS-RHEL-Jul-2013-v01 Patch +
ALSMS-OS-RHEL-Sep-2013-v01 Patch
OS Requirements for new installs:
RHEL 5 32-bit Linux
ALSMS-OS-Install-RHEL-Sep-2013-v01
Iu ProtocolConverter
OS requirements for the cards used in IPCFMS - SunOS 01 5.9 Generic_122300-27 sun4u sparc SUNW,Netra-CP2300GICC 1.1 - VxWorks (for Artesyn Spiderware NP 8260) version 6.2Kernel: WIND version 2.8.CICC1.1 - VxWorks (for Artesyn CICC750F) version 6.2.
Kernel: WIND version 2.8.
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 15
3.4 Upgrade paths
Only the following configuration of NE loads has been certified in Alcatel-Lucent labs ascomprising this load. If applying this load, please plan to update all NEs to be consistentwith this reference configuration.
3.4.1 FBSR Upgrade Paths
From Release To Release
BCR3.0.3.8
(FBSR-03.00.84)
BCR4.3*
(FBSR-04.03.31.a.2)
BCR4.1.2.2
(FBSR-04.00.63.a.12)
BCR4.3*
(FBSR-04.03.31.a.2)
BCR3.0.3.8
(FBSR-02.60.77)
BCR4.3*
(FBSR-04.03.31.a.2)
BCR3.0.3.8
(FBSR-03.00.84)
BCR4.3.1
(FBSR-04.03.41)
BCR4.1.2.2
(FBSR-04.00.63.a.12)
BCR4.3.1
(FBSR-04.03.41)
BCR4.1.2.5
(FBSR-04.00.63.a.16)
BCR4.3.1
(FBSR-04.03.41)
BCR3.0.3.8
(FBSR-02.60.77)
BCR4.3.1
(FBSR-04.03.41)
BCR4.3
(FBSR-04.03.31.a.2)
BCR4.3.1
(FBSR-04.03.41)
* These particular paths are superseded by the equivalent path into BCR4.3.1
Can upgrade from any BCR2.6, BCR3.0, BCR4.1 load to 04.03.41
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 24
Features with limitations
A feature with a limitation is an operational feature with known and acceptable issues,deployable to start First Office Application (FOA) activities and trials.
Limitations can be linked to testing limitation, issues or a specific configuration.
FeatureID
CR FeatureTitle Limitations description
Release FeatureIntroduced
113161
131828
118878
2ms TTI on E-DCH
Limitations remaining
• If CS & PS co-exist (on same UE), no PS on 2ms
If CS exists and PS comes in, establish on a
10ms PSIf PS exists and CS comes in, PS is“dropped” to allow CS. PS will re-establish and then it will be on setup on 10ms
• No Compressed Mode for PS on 2ms
Select DAHO instead of MAHO for 2ms TTIuser
• Max 2ms TTI user = 1
Lab results indicate sub-optimal throughputif max 2ms users > 1
If 2ms PS user exist already, subsequentusers on 10ms have better throughputcompared to if they were on 2ms
• Lab/demo only restriction on PC302 (Home
deployments)Having 2ms call means data rate on otherusers drop to 0K throughput.
BCR2.4
124168 1088805 DPDK supporton 9365 BSR-GW
There is a higher than expected SCTP/IP message rate to beexchanged between the DPDK application and the Linux KernelIP stack.
Load test analysis shows 30% CPU usage per core to process100,000 PDU/s
Sub system load test shows 20% CPU usage per core for
BCR4.3
159532LR Metro Cell Outdoor Traffic Management -Daisy Chain
Certified with BCR4.3.1 BCR4.3.1
163133 LR MCO MS Transport and QoS Management Certified with BCR4.3.1 BCR4.3.1
1711319764 Metro Cell Outdoor Wi-Fi AP - Wi-FiCommercial launch in BCR
Certified with BCR4.3.1 BCR4.3.1
171231WCDMA OAM support for MCO Wi-fi AP Certified with BCR4.3.1
BCR4.3.1
172448 WTA validation in BCR4Certified with BCR4.3.1 BCR4.3.1
170881170881 3G-4G & 3G Group sniffing co-ordination
Certification targeted Jan 2014
(This features uses featurescontained in BCR4.3.1 load forSMP integration)
BCR4.3.1
1-4708449/
1068292WMS profiles issues (enhancement)
Certification with BCR4.3.1 -Delivery of BSR profile changesmanagement during upgrade
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 25
200000 PDU/s
While the behaviour is a system improvement over previousreleases further improvements can be realised by replacing theTAP interface with KNI interface, timeframe TBD
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 28
3.11 Limitations
V2.x or higher CPE hardware running on BCR 3.0.3 or later software needed.
Maximum one Femto per link/modem. No sharing of single link by multiple Femtos.
Femto over satellite backhaul will only support fixed location deployments e.g. cell in avillage, rural area.
Class of Service (CoS) based queuing has to be configured in the satellite equipment.
As it cannot be guaranteed that the satellite backhaul has sufficient bandwidth resources,voice call admission depends on how the satellite modem provides bandwidth capacity(important for emergency calls)
ALU KPI not compliant for satellite backhaul
Low data throughput for PS call (depends of satellite backhaul context)
3.12 Not Supported
• Location lock and national lock (disabled)
• Small Cell mobility over satellite e.g. small cell in ship, car, ferry, train
• Bandwidth measurements (disabled)
• Femto to Femto handover (disabled)• Femto groups
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 29
4 LIST OF SET-UP INFORMATION, KNOWNISSUES, WORKAROUNDS
This section identifies known issues, workarounds or required set-up information asidentified by the design, test and FOA teams. Issues are all tracked by Change Requests(CRs) according to the standard process. CRs are either:
Open Priority 1 (P1) and Priority 2 (P2) CRs, under investigation (i.e. issueconfirmed, but fix not yet available).
or
already planned for being fixed in next releases.
4.1 Silent Reboot issue (with change in CPU frequency CR906938)
4.1.1 Summary
In V2 Metro boards, a silent reboot is observed randomly (some units displayed frequentoccurrence and some very rarely or not at all). Note: Change also affects Light radioboards.
Investigation resulted in a hardware modification. However, a work around is available toachieve stability by reducing the CPU frequency.
PC3x3 ARM core by default boots at 600Mhz and during kernel boot the CPU frequencyis scaled up to 700Mhz as per the datasheet.
If we avoid frequency scaling and run at default boot speed of 600Mhz, the frequentlyrebooting units displayed better stability.
Hence this is a MIM controlled way of setting the CPU frequency to either 700Mhz(default) or 600Mhz (on operator's preference).
This CPU frequency change via MIM involves a system reboot and has to done during amaintenance window.
4.1.2 Impact of Frequency Change
This change affects both V2 Metro and Light Radio boards.
Minor impact for single UE / 64QAM / HSDPA / DL.
Minor impact for two UE / 64QAM / HSDPA / DL.
No voice quality impact.
4.1.3 How to do this via MIMsparePara11 - is the MIM parameter used to control this customization.
* If this attribute is empty no action will be taken
* The string entry values are case sensitive
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 30
4.1.4 How to verify current CPU Frequency
cat /proc/cpuinfo
...
BogoMIPS : 696.32
...(is the frequency in Mhz)
4.1.5 How to enforce 600Mhz CPU frequency
< Attr name="sparePara11">
<String>cpuClk=down</String>
</Attr >
1. If this attribute is empty no action will be taken
2. If this attribute contains “cpuClk=down” string and the board is already running at 600Mhzno action will be taken.
3. If this attribute contains “cpuClk=down” string and the board is running at 700Mhz, the
code triggers a reboot indication to OAM and OAM reboots the system.4. On next reboot the CPU Frequency will be 600Mhz. This can be verified with the cat
/proc/cpuinfo command.
4.1.6 How to revert back to 700Mhz from 600Mhz CPU frequency
< Attr name="sparePara11">
<String>cpuClk=up</String>
</Attr >
1. If this attribute contains “cpuClk=up” string and the board is running at 700Mhz no actionwill be taken.
2. If this attribute contains “cpuClk=up” string and the board is already running at 600Mhz,
the code triggers a reboot indication to OAM and OAM reboots system.3. On next reboot the CPU Frequency will be 700Mhz. This can be verified with the cat
/proc/cpuinfo command.
4.1.7 How to enforce 600Mhz on a specific unit
1. This has to be done via the same "sparePara11" with the same value ("cpuClk=down") asbefore but done via the Management system i.e. via a BSR_CONFIG message.
2. This procedure has to be done during a maintenance window as this involves a systemreboot to take effect.
4.2 BSR Spare Parameter Workarounds
Complete spare parameter deltas are detailed in release operational impact documents. Available via OLCS at the following location:
Contains “intraBsrOwnEcNo” and “nbrBsrHOAbsThresh” for optimisation of intra frequencyhandover. Settings to be determined from deployment optimisation.
nbrBsrHOAbsThresh:
Defines the CPICH Ec/No threshold for BSR neighbour cells reported in UE measurementsat which handover will still be favoured to the BSR neighbour cell even when Macroneighbour cells are reported by the UE with higher CPICH Ec/No.
The syntax is “nbrBsrHOAbsThresh=<value>”, where the value is an integer with range [-24..0], default=-13, unit=dB. If not set, the value -24dB will be used and BSR neighbour
cells reported by the UE will always be favoured for handover before macro neighbourcells.
intraBsrOwnEcNo:
If measurement reports for event 1C contains better BSR neighbour cells, only attempthandover to those neighbour BSRs if CPICH Ec/Io reported for the serving cell is notgreater than intraBsrOwnEcNo.
The syntax is “intraBsrOwnEcNo=<value>” where <value> is an integer with range[-24..0].which corresponds to CPICH Ec/N0 of the serving cell specified in dB. If not set the value0dB will be used and handover will always be attempted to a better cell.
The setting of intraBsrOwnEcNo must also consider the setting ofBSR::psInterferenceThreshold to ensure that handover of a PS call will be attemptedbefore the Target Cell Protection (Interference Reduction) is activated.
4.2.2 Spare Parameter 10 (CR 898131)
RlctCphNoEncInf controls whether a target cell will support incoming relocation of a UE onwhich ciphering has been started but when the core network does not populate EncryptionInformation in the relocation request. Normally it is expected that Encryption Information ispopulated when ciphering has been started, however RlctCphNoEncInf set to true - allowsincoming handover to be supported for exception scenarios (for example Emergency calls
without ciphering, but when ciphering is already started on the UE).The Syntax is ““RlctCphNoEncInf=True”, if not set the value false will be used andrelocation request will be failed under the described scenario.
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 32
4.2.3 Spare Parameter 15 (CR 895263)
This is used for timer for handover failure improvement. It contains string‘tBsrRelocAudit=<valueT>; mBsrRelocAudit=<valueM>’ where <valueT> is a time in therange 0..30 seconds and <valueM> is a count of UL message in the range 0..30. If thestring is not present, <valueT> and <valueM> will default to 0.
valueT is the time in seconds the source cell waits before performing an audit for the UE todetermine if it is still present following the start of the handover procedure, if set to 0 thetimer is not started. valueM is the number of UL messages received on the source cellfollowing the start of the handover procedure that will trigger an audit to determine if the UEis still present, if valueT is non zero and valueM is set to 0, UL messages received on thesource cell will not trigger the audit. The UE audit will be performed on the earliest of thetimer expiry or the UL message limit being reached.
4.2.4 Spare Parameter 20 (CR 922567)
sparePara20 is used to set the file size for generating the neighbour list summaryinformation, e.g. it contains “neighFileSz =100000”, if unset (or set to 0), the file will not
be generated. Note the file is written to /tmp/measData.txt
4.2.5 Spare Parameter 23
SpareParam23 when set to ”HC=0,1,2,3,4;” provides a work around for CR 916077 wherethe SRNC ID is temporarily modified during small cell to small cell handover for certain UEtypes (Motorola Atrix 2 4G, MB 865, Samsung i997 Infuse 4G, Motorola Atrix 2 ME 865)
4.3 FMS Radius Password Server Configuration
4.3.1 How To Enable this Feature
To enable this future Small Cell Radius feature deployment: The feature is activated by
filling the shared secret into Small Cell " passwdSharedSecret" attribute, If the attribute is
left at its default value (zero-length string) then the feature will not be activated. If it is not
activated, then the Small Cell will fall back to using fixed passwords.
4.3.2 Nominal Case Scenario
Password string restriction: secret should be at least 16 bytes and less than 128 bytes." @this point [SEC EncryptSecret -entity FEMTO -secret "< anypassword >"]
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 33
attribute and write the LDAP server IP address to the
FemtoCluster BSRClusterProfilepasswdServerFQDN attribute in the WMS database.)
Then register the femto and in the bulkcm file there will be an attribute
passwdSharedSecret containing the decoded password. Small Cell will use this file for
authentication. For successful authentication you should declare NAS at WMS. Running
the configure_radius.sh script.
1. Log in to the network management server with the Alcatel-Lucent account. Refer to
Logging in to an OAM server for assistance.
2. Enter: su - root
3. At the Password prompt, type: <password>
- where <password> is the password for the root user ID, the password should be at least
16 bytes but less than 128 bytes
4. Change directory to the RADIUS configuration script:cd /opt/nortel/shell/security
5. Type the following command:
./configure_radius.sh -subcomponent clients (Write the femto IP as the radius client IP,
sharedsecret as the decoded script, and Not_Specified as the radius NE type)
4.3.3 Which Condition It Should Fail
If the user doesn’t have sufficient rights to generate WICL script it should fail while running
the SEC EncryptSecret command.The user connects to FEMTO with a wrong user name and/or password,
NAS IP@ in not available in the NAS allowed list,
Inconsistent configuration between Radius server configuration and FEMTO provisioning(shared secret, ServerIP@), Radius server is stopped/ Ldap Server is stopped.
4.3.4 How To Configure WMS-For-Small Cell Server To Allow WIPSAccess Even If RADIUS Was Setup For Small Cells
NOTE: Configuring clients subcomponentWhat action do you want to perform [list(default), add, remove]: addEnter radius client IP or subnet to ADD ( "end" to terminate ): 127.0.0.1Enter radius client shared secret []: <entered "alcatellucent" without quotes>Enter radius client type [(no default)Not_Specified rnc1500 poc Bts]: Not_SpecifiedNOTE: Adding Radius server client: 127.0.0.1Enter radius client IP or subnet to ADD ( "end" to terminate ): endNOTE: Done adding new radius client(s) successfully.
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 35
4.5 EDCH 2ms to be used in demos only
See section 3.7.2 “Features with limitations”
4.6 Macro to Femto Hand Over behaviour
During incoming Macro to Femto Hand Over, if the BSR baseband load check fails, thewhole procedure shall fail and no downgrading is applied. DBC downgrade of existingcalls is not performed to support the incoming handover. This is to avoid existing callsbeing impacted if a target cell has been incorrectly selected for the handover (due to PSCreuse, target cell selection may not be correct).
4.7 Modification of 32 user feature parameters
Modifying the below parameters from the supplied defaults is not recommended, as it couldlead to system instability when the 32 user feature is enabled:
Lcell::r99psUserThrsLcell::r99PsUserRate
Lcell::r5psUserTHrs
Lcell::R5PsUserRate
These parameter recommendations are designed to limit the BCR4.1 new capability tomore efficiently assign RAB rates on the UL given an improved UL baseband resourcesestimate algorithm.
In an ideal lab environment, with these parameters NOT set, then the benefit to the userwould be: Higher R99 RAB rates being allocated more often
However, in the real world environment more RF triggered overload problems could lead todropped calls/RRC connections and high risk signalling procedures
The parameters settings are designed to provide a greater emphasis on system stabilityrather than R99 RAB rates (fewer and fewer R99 UEs in the field) and the aboveparameters settings effectively LIMIT the UL RABs rates granted
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 37
1100077 1-4764068Call Drop - CS Iu-ReleaseCommand not processed (no RB Release) duringPhysicalChannelReconfig
1112043 1-4810350 BSR::maximumAllowedNtpJitter threshold limit too restrictive for Satellite Backhaul
5.2 9365 BSR Gateway
The following table provides the list of Change Requests (CRs) fixed.
CR AssistanceRequest
(AR)Abstract
858427 Resiliency:subscriber test 19.04 reports less than 99 IMSI's output at WMS
1059939 DPDK is not coming up as default enabled after Kernel Upgrade from 3.0 to 4.3
1069288 [ATCA RTM Port Bundling] - Intra switchover needs to be done when 50% of the ports for aparticular cluster configuration is observed.
1076592 generic NAT proxy failing to create
1087921 4.3 network upgrade-> connectionType needs to be "logical" for for InterfaceType cnCSCP1 forboth SUN and ATCA.
5.1 VPN Firewall Brick
The following table provides the list of Change Requests (CRs) fixed.
CR AssistanceRequest
(AR)
Abstract
1325039 The previous default key algorithm and length in the Certificate Manager for creating a CSR wasRSA 1024. This is no longer considered secure enough so the default is changed to RSA 2048.
1325044 When using certificates to authenticate a tunnel with IKEv1, the Brick may leak memory.
1325051 Certain detailed log messages from within the actual IKEv2 protocol handler are not being sent.
1325053 If an IKEv2 tunnel has little to no data traffic and heartbeats (i.e Dead Peer Detection) are (is)enabled, then rekeys may fail if the rekey falls in the same polling cycle as the heartbeat attempt.
1325055 The Brick may leak memory when certificates are applied to the Brick or it may panic.
1325058 When a Femto BSR has an IKEV2 tunnel established with the Brick and the FBSR changes NATbindings, the Brick leaks memory.
1325063 When you change the certificate assigned to a TEP, the old one is not removed.
1325065 Brick may panic in certain IKEv2 error conditions
1325069 Loading a large CRL can cause packet processing to be interrupted for up to several seconds ona Brick model 1200r3 for very large CRLs(~5MB).
1325072 If there are multiple LAN-LAN tunnels defined that share some, but not all, of the remote hostaddresses, then the Brick may panic after failover.
1325074 If AAA is slow to respond because of Java garbage collection, ALSMS mistakenly thinks the AAAis down and switches to the secondary AAA server. The secondary does not respond to somemessages because they are part of authentication sessions that were started on the primary.
This causes ALSMS to think the secondary is down so it switches back to the primary. Thisbouncing continues until ALSMS is rebooted. ALSMS should not switch AAA servers in themiddle of an authentication session.
1325077 In an unusual race condition, the Brick may panic.
1325079 With heavy IKE load and/or certain error conditions, the Brick may panic.
1325082 Very rarely, model 1100A and 1200 Bricks with both manually keyed and IKE tunnels may panic.
1325086 The database auto-repair feature attempted to repair the database on a secondary ALSMS if itwas not able to sync with the primary ALSMS for more than 60 minutes. Unfortunately thisfeature sometimes caused the secondary to get stuck in a loop restarting services. This change
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 38
disables the auto-repair feature unless it is specifically enabled on the secondary ALSMS with"secondary.enableSelfRepair=true" in the config.ini file. The dbsetup utility may be used tomanually sync the secondary ALSMS database with the primary ALSMS if automaticsynchronization fails for some reason.
1325087 If the Brick has an IKEv1 tunnel established using certificates, it will panic when an apply isdone.
1325091 This change increases the performance of the Brick model 1200R3 Basic.13250831325093
If the Encryption Accelerator card fills up with Security Associations (SAs), the Brick will panic.The capacity is 262,000 SAs, so this is not normally reached, but it has been seen on thestandby in some unusual test scenarios. Additionally, the Brick may panic after it goes active.
132503513250641325080
This improves the number of tunnels per second that the Brick can establish - especially forGroup 5 and Group 14 Diffie-Hellman.
132505013250521325089
If you configure a client IKEV2 TEP to allow the Brick to create a second child SA, there weremultiple issues with the way the Brick handles them including creating incorrect traffic selectorsand deleting the wrong SA under certain circumstances.
132504013250421325043132504613250471325049
1325062
Performance improvements for UDP encapsulated IPSec traffic.
5.1 8950 AAAFor AAA list of Change Requests (CRs) fixed, please refer to the documentation link available in
section 3.4.6.
5.2 Small Cell Management System (SCMS)For SCMS list of Change Requests (CRs) fixed, please refer to the pdf file available in section 3.2
SCMS Release Notes.
8/20/2019 BCR4.3.1_V1_Small Cell Cluster Release BCR4.3.1 - Release Letter
3 BCR4.3.1 TBD CP regression:Less uplinkthroughput is observed for R6 cat4UE in 2msec on PC333
Cat4 UE for 2ms TTI is giving throughput 1.2 mbps, Cat6 Ues give good throughput(meeting requirements)expectation is UE population in the field ishigher for Cat6, in addition as 2ms TTI is oavailable for 1 user per Femto, the frequewhere this degardation of throughput is visis very low
Only two, sometimes three of the calls arehanded over. The other calls are droppedThis is only applicable to Broadcom baseCPEs
6.2 9365 BSR Gateway Open CR / AR
CR / ARnumber
Sev Found In Targetdate for
resolution
FeatureName or
ValidationCriteria
Description
Description of missingfunctionality or reason for
blockage
Impact of missing functionality(implications and mitigation)
1-4830001
3 BCR4.3 TBD FOA
FOA BCR4.3: FGW constraintcheck failed for superLAC whendownload new DB from WMS
When bulkCM file is downloaded from WMto FGW, some checks are performed on Fand it errors on superLAC values which isoptional. In case when superLAC is send <unset>, though download was successfu
there was problem in sending the dbStatuWMS (setting of AVCN).
RELEASE LETTER 15TH November, 2013 SMALL CELLS BCR4.3.1
Alcatel-Lucent – Proprietary
See Notice on Page 2 40
To change the boot order list:
/usr/board/tools/bios/mod_bol.sh
1111435
3 BCR4.3.1 BCR4.3.1maint
[SUN Resiliency]:Changes are notgetting reflected to Satndby BSGafter connecting the internodecable in SUN system.
It may result in outage in case ofswitchover/failover scenarios due to the Odata sync issue. Scenario worked properlyBCR4.3 release and issue observed only SUN but not on ATCA.
1117174
3 BCR4.3.1 BCR4.3.1maint
NLT-BCR-4.3.1:In Releasedocument bono.cfg configurationsection two different nameserverip is mentioned wrongly for eth2and eth3
This is document CR only, User has to mothe bono.cfg file before doing freshinstallation.
1102639
3 BCR4.3.1 BCR4.3.1maint
[Stability]shelfoam.exe core dumpobserved with minimal load run
ATCA shelf level alarms will not be reportduring this time(3-5 sec)Workaround :shelfoam.exe will restartautomatically
1117034
3 BCR4.3.1 BCR4.3.1maint
4.3.1 network upgrade-> SCTPassociation with newly comingFGW not happened up to it cameas active during KU to .04 load.
When BSG is upgraded, an 7 minute delahas been introduced between upgrade ofindividual gateway cards. The purpose ofdelay is to enable the active warm standb
feature to ensure that the upgrade can ocwithout an extended loss of service. (Notthat any calls active at the point when thegateway fails over as part of upgrade will dropped, but the amount of time during whnew calls can’t be established will be limitto a few seconds, and the small cells will nstop radiating).
1111435
3 BCR4.3.1 BCR4.3.1maint
[SUN Resiliency]:Changes are notgetting reflected to Standby BSGafter disconnecting andreconnecting the internode cablein SUN system.