Figure 33 shows the scenario for gateway handover. It is considered that the source gateway and the target gateway are associated with the same NCC and with the same satellite. A gateway handover always entails a beam handover, so the beam handover procedure is tightly integrated and synchronized with the gateway handover.
Source Scheduling Area Target Scheduling Area
Source Gateway Target Gateway
NCC
Satellite Gateway Handover
RCST
Figure 33: Gateway Handover scenario
The flow chart of a gateway handover procedure is shown in figure 34. The following clauses explain the whole handover procedure.
Figure 34: Gateway Handover procedure
8.3.1 Handover Detection
The handover detection is the same as that of beam handover. Various approaches can be used for the detection of a beam handover including position based detection, link quality based detection. This can be performed either centrally at the NCC or in a distributed manner by the RCSTs. The handover detection algorithm is outside the scope of the present document, although the position-based detection is the preferred mechanism for train applications where it is highly likely that a GPS receiver or other navigation system is installed. If the position-based approach is adopted, it is assumed that the NCC contains a database that includes all beam, gateway and satellite profiles and this same database will be passed from the NCC to the RCST at its logon phase or at regular intervals. The RCST will combine its position information and the beam profile information together with the pre-defined train route for handover detection. If a beam handover is required, the RCST sends a handover recommendation to the NCC. The handover recommendation will include a list of candidate beams. The recommendation message is encapsulated within the Mobility_Control_Message as defined in the beam handover procedure, which is carried in DVB-RCS SYNC burst.
8.3.2 Handover Decision
In the handover decision phase, the resource availability of the candidate beams, the SLA and QoS of the session to be handed over will be checked by the NCC. The handover decision will also take into account the mobility trajectory if it is known, such as the case of a train route or a flight path. Once a target beam is chosen, the NCC will check if the chosen target beam belongs to another gateway. If the target beam belongs to a new gateway, a gateway handover is decided. Normally it is assumed that the FL and RL have the same beam coverage and gateway configuration so that FL and RL handovers happen simultaneously.
Once a handover is decided, the NCC will update its SI tables, which include the TBTP, SCT, FCT and TCT. Signalling will be carried out between the NCC, the source and the target GWs for the preparation of handover. The NCC will send an SNMP Set-Request message to the target gateway for events synchronisation to ensure that the target GW gets ready for connection with the RCST. The updated SI tables, together with the routing update information of the RCST will be included in this message. The routing update information is generally implemented by sending the location change information to the broadcaster, which is generally handled by the location management scheme. Upon reception of the Set-Request signalling, the target GW will allocate bandwidth resources for the RCST according to the new burst time plan sent by the NCC. This will be followed by an acknowledgement Get-Response message sent from the target GW to the NCC. The NCC will then send a Set-Request message to the source GW, which includes the RCST identity and the SI tables. At the source GW, after receiving the NCC signalling, it will buffer the FL user traffic to be
forwarded to the target GW during handover. The source GW updated its route mapping table and released resources used by the RCST. The source GW will then acknowledge the NCC by sending it a Get-Response message.
8.3.3 Handover Execution
Upon reception of the Get-Response message from the source GW, a gateway handover command is issued to the RCST from the NCC in a Mobility Control Descriptor carried in a TIMu message. Upon reception of the handover command, the RCST synchronizes with the NCC and the target GW, retunes itself to the new beam and receives traffic from the new beam which comes through the new gateway. In the FW direction, the traffic to the RCST is redirected to the new gateway and then through the new FL to the moving-in RCST. On the RT direction, the RCST sends return traffic and signalling on the new RL and through the new RL to the new gateway. The gateway handover is complete when the RCST sends an ACQ message to the NCC after it finishes the retuning process and receives the CMT message from the NCC.
The signalling sequence flows as depicted in figure 35, where the Functional Entity Actions (FEAs) are also shown.
FEAs are internal actions of the functional entities in preparation for or in response to their associated signalling messages (see table 11). In order to facilitate M&C message communication, DVB-RCS management is extended with newly defined SNMP messages in the format of Trap, Set-Request and Get-Response. The higher layer SNMP interaction (indicated by solid lines) and DVB FL/RL signalling (indicated by dotted lines) are synchronized and coordinated to accomplish the entire HO management.
Figure 35: Gateway Handover Signalling Sequence
Table 11: Gateway Handover Functional Entity Actions
FEA Number FEA description Comments
FEA1 Periodically check the positioning/link quality information, triggering HO Recommendation on criteria agreements.
Refer to beam HO mechanisms [RD-3]
FEA2 Make HO decision, identifying it's HO type, i.e. beam HO, GW HO or SAT HO.
FEA3 Set resource arrangement taking account to the new moved-in RCST.
FEA4 Arrange resources for moving-in RCST.
FEA5 Send resource allocation update response to the NCC.
FEA6 Set resource arrangement taking account to the moved-out RCST.
FEA7 Send Set-Request for moving-out RCST to forward the traffic.
FEA8 Prepare to release resources for the moving-out RCST, forward the traffic.
FEA9 Send resource allocation update response to the NCC.
FEA10 Receive resource allocation update response.
FEA11 Issue HO CMD in source beam, indicating Target beam/GW/SAT.
FEA12 Retune to target beam. Switch to new link. Refer to beam HO mechanisms FEA13 Issue general SI tables in target beam. Refer to beam HO mechanisms FEA14 Use new resources in target beam. Refer to beam HO mechanisms FEA15 Send ACQ in target beam. Refer to beam HO mechanisms FEA16 Receive ACQ in target beam, indicating RCST
re-synchronisation.
Refer to beam HO mechanisms FEA17 Send CMT to moved-in RCST in target beam,
confirming the HO complete.
Refer to beam HO mechanisms FEA18 Receive HO confirmation indicated by CMT. Refer to beam HO mechanisms