定时和同步

大自然中的变色龙仅需0.02秒,即可捕捉到它的猎物。 但今天通信网络需更快的速度才能满足需求。测量精准度需小于0.000000001秒,以确保网络定时和同步符合国际标准, 并提供强大和可靠网络的性能。

在团队开展空口测量

Sync testing has always been physical. Interfaces, line rates, cabling and equipment. Whether on site or remote, a physical connection is required to test whichever part of the network is of interest. Guided by the ITU-T standards – G.8271.1/G.8271.2 for example, the network can be tested and maintained to deliver accurate Synchronisation through the backhaul.

These standards specify an end-to-end requirement of 1.5µs, from the PRTC to the output of the air interface. However, for the Transport guys, the backhaul is their domain which demands 1.1µs or 1.35µs up to the network endpoint – before the air interface.

There is also the case of site access. Small Cells for example tend not to have 1pps outputs, therefore measuring the sync performance from the Small is not possible, unless you can measure the sync on the air interface of course… Or perhaps the Basestation of interest is simply inaccessible, being able to make 1pps measurements over the air would save a lot of time and hassle.

Sync is typically a Transport responsibility, therefore the final ITU-T requirement of 1.5µs or small cell sync is not actually tested, being on the air side – the RAN domain.

For the RAN teams, the air interface is their bread and butter, however Synchronisation is a filling yet to be spread on the RAN club sandwich. Sync is not a responsibility of the RAN team, and the communication with Transport team may not be optimum, if Sync was to become a RAN responsibility. This could pose a dilemma for the operator when trying prove conformance to ITU-T standards – the 1.5us requirement – how do you know that performance is being met at your customer interface? Whose responsibility is it to test?

This highlights the fact, that using Sentinel to test the 1.5µs sync requirement on the air interface, would require the Transport guys to venture into somewhere they’ve had no reason to before. There is one question we could ask with regards to testing Sync on the air interface; is it your responsibility to make sure the network is synchronised in accordance with ITU-T G.8271.1? If the answer this question is yes, then that could mean one of two things:

The responsibility will be passed on to someone else (RAN team) who already test the air interface as part of their daily/weekly routine, albeit out with Synchronisation. If this is the case, then engineers with potentially no experience in Sync, will have to get up the learning curve and liaise with the transport team to test Sync. It would also add to their existing responsibilities.

1. The responsibility will be passed on to someone else (RAN team) who already test the air interface as part of their daily/weekly routine, albeit out with Synchronisation. If this is the case, then engineers with potentially no experience in Sync, will have to get up the learning curve and liaise with the transport team to test Sync. It would also add to their existing responsibilities.

2. The Transport teams will have to change the way they test and troubleshoot sync issues in the network, with a new (air) interface to deal with. This may involve travelling to a test site/cell tower, whereas before they may have been able to test the backhaul remotely. No change to their responsibilities here, only method. The one issue to be aware of, is that Transport would be encroaching on RAN territory, a dilemma that will need to somehow be negotiated.

So with the advent of sync testing over the air (OTA) with the Calnex Sentinel, it’s now possible to test that final ITU-T requirement of 1.5µs at the air interface, redefining sync troubleshooting in the process. The questions to think about are; now that we can test beyond output of the physical network, who would be responsible for testing and maintaining the sync on the air interface? How would that work? Do you change the process for the Transport team? Or do you change the team?