You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Current guidelines from the Gander Oceanic Knowledgebase (linked from nattrak site) give the following timing guidelines:
too late: if within 15 minutes of OEP, nattrak rejects your request and tells you to ask via voice
ideal: aim to submit your clearance request at least 30 minutes ahead of time
too early: no limit is stated on how early is too early to submit a request
Feedback from controllers on oceanic positions during CTP indicated that they were occasionally getting requests from aircraft 2+ hours out from the OEP. This is too far out to have a reliable ETA over the fix, as shortcuts or small mach changes could easily push the ETA out of range of the original time stated in the clearance request. So they'd like a maximum early time to be added to the set of time constraints.
In my opinion, the accuracy of the time is more important than having an enormous lead time. Processing the clearances doesn't take 30 minutes, it takes (max) 30 seconds. The larger systemic issues have to do with inaccurate ETAs filed in nattrak, which later result in clearances issued by DEL which in nattrak, are clean... but in reality the aircraft are tied at the OEP, with the domestic controller's plugin showing that oceanic wants them at the same altitude, because nattrak thinks they'll be separated longitudinally. With that being the highest priority, I would advocate for as little lead time as is reasonable, while also giving enough buffer and lead time to be able to troubleshoot the requests that have complex conflicts.
Given all of that, I propose the following timeframes:
too late: 10 minutes from OEP
ideal: 30 minutes from OEP
too early: 45 minutes from OEP
I believe these times would ensure a higher degree of accuracy of ETAs, better matching the nattrak picture to the reality of the traffic situation. But others may feel differently, so additional discussion may be warranted.
The text was updated successfully, but these errors were encountered:
Based off the feedback meeting rejecting ETAs over an hour from present time was requested so I'll that at first.
Perhaps an alternative method could be 'saving' the request and then submitting it properly later on? This could be done with Laravel jobs but requires extra overhead.
Also, should we reject clearances that are too late or just highlight that to the controller so they can do Revert to Voice?
Current guidelines from the Gander Oceanic Knowledgebase (linked from nattrak site) give the following timing guidelines:
Feedback from controllers on oceanic positions during CTP indicated that they were occasionally getting requests from aircraft 2+ hours out from the OEP. This is too far out to have a reliable ETA over the fix, as shortcuts or small mach changes could easily push the ETA out of range of the original time stated in the clearance request. So they'd like a maximum early time to be added to the set of time constraints.
In my opinion, the accuracy of the time is more important than having an enormous lead time. Processing the clearances doesn't take 30 minutes, it takes (max) 30 seconds. The larger systemic issues have to do with inaccurate ETAs filed in nattrak, which later result in clearances issued by DEL which in nattrak, are clean... but in reality the aircraft are tied at the OEP, with the domestic controller's plugin showing that oceanic wants them at the same altitude, because nattrak thinks they'll be separated longitudinally. With that being the highest priority, I would advocate for as little lead time as is reasonable, while also giving enough buffer and lead time to be able to troubleshoot the requests that have complex conflicts.
Given all of that, I propose the following timeframes:
I believe these times would ensure a higher degree of accuracy of ETAs, better matching the nattrak picture to the reality of the traffic situation. But others may feel differently, so additional discussion may be warranted.
The text was updated successfully, but these errors were encountered: