IFPS reroute accepted

[White Hart]

'RMK/IFPS REROUTE ACCEPTED'

I put this remark on virtually every IFR flightplan I file - and that's a lot of flight plans! The response from IFPS is varied - sometimes a reroute is offered as an add-on message, sometimes the FPL is actually rerouted, sometimes I will receive a telephone call to discuss the FPL, sometimes I receive a rejection message with reasons included, but nothing else in the way of an alternative route or a solution to the rejection.

My question to the IFPS boys and girls is - if I put 'IFPS reroute accepted' on the FPL, why the different responses? Surely the response every time should be a revised/rerouted FPL if the original is rejected.

[Pierre Argh]

Firstly I don't work for IFPS... but I'm guessing, they don't have time or resourses to trouble-shoot every flight plan that doesn't comply with the increasingly complex routing, one-way systems etc... and if you have made a significant error (heaven forbid) in the FPL they would be left trying to second guess you. I believe the "re-route accepted" allows for small alterations to the filed plan... not major revisions, and is probably frequently overlooked?(I accept this may not explain all your rejections)

[White Hart]

More like 'luck of the draw' perhaps?

problem is, when we put the RMK on the FPL, then receive a rejection with no further info or advice, the buck is effectively passed to us. It's us at FBU who have to explain to the operator that the FPL is unacceptable, and then we look really professional when they ask for our advice to resolve it - and we don't know the answer either!

The last thing I like doing is having to send the rejection back with a handwritten "please refile" scribbled on the bottom

If the RMK is annotated on the FPL, then I would at least expect some sort of explanation for resolution of the rejection. This does not always happen. There is even talk amongst some ATSAs at LL FBU at the moment that its because somebody at IFPS has said "if we (IFPS) don't think they've (the operators) made a genuine attempt to correctly file the route themselves, then we're not going to do it for them - send it back and let them have another go"

Whilst I will be the first to agree that flight planning can be very complicated (especially within the IFPS 'region'), I still think that IFPS is obliged to attempt to rectify routing errors when they occur, and not just simply reject the FPL. Otherwise, there's no point in having the 'reroute accepted' remark annotated in the first place.

[routechecker]

White Hart,

First bit of backgroung on this IFPS re-route accepted concept.
When IFPS first came online 10 years ago (time flies when you're having fun ) the official line from the airlines was -"It's my flight plan, don't you dare touch it". Fair enough, we did not, so except for minor "cosmetic" corrections to syntax errors not a lot more was done. Then again the RAD, when it used to be called TOS and then SRS was much simpler and not implemented with all the details as is today.
Then the Balkan crisis started. With the airspace closures, the re-routing effort by the AO's was massive. In the early days of the crisis at IFPU2 it was common to see the invalid queue of messages go up to numbers close to 500/600. That meant that if your FPL goes into manual now, for argument sake at 08:15Z, you can count on having either a ACK or a REJ at 10:15Z. If it's a REJ you could start again. Absolutely nonsensical I agree and so did a lot of AO's who started including "IFPS rerouting accepted" or some variation of it under RMK.
Over the years this has evolved into the following legal concept:

Requirements
The IFPS Re-route Accepted feature is subject to those conditions applicable in the
Quality of Submitted Messages (see § Quality of Submitted Messages) and should not be
considered to take priority over that instruction.
The comment ‘IFPS Re-route Accepted’ in the sub-field RMK (see § Item 18: Other Information),
of a flight plan shall be considered as written authorisation from the message originator for the
IFPS staff to manually correct the message where necessary and possible, without being
required to obtain further agreement to those changes from the message originator.
It shall then be the responsibility of the message filer to ensure that any changes made to that
message by the IFPS are checked and communicated to any necessary persons prior to the
departure of that flight.
It shall remain the responsibility of the message filer to ensure that, where a message that
includes this remark is submitted to the IFPS, that message filer shall have the means to receive
the updated version of the message after any possible manual processing by IFPS (see § ORM).
Those messages filed via an AFTN address located outside the IFPZ that has not been
registered as ‘known’ in the Environment database shall not receive any operational reply
messages (see § ORM) and must ensure that they have the means with which to receive
any updated versions of messages. It shall also be necessary for the message filer to ensure
receipt of any updated messages that may be filed through a gateway address.
It shall not be the responsibility of the IFPS to confirm that the aircraft operator receives a copy of
any updated message containing the ‘IFPS Re-route Accepted’ authorisation.
Message Format
Where a message filer wishes to authorise the IFPS staff to make amendments to their submitted
messages when necessary and possible, that message filer shall add the comment ‘IFPS
REROUTE ACCEPTED’ in the RMK sub-field of the submitted message.
Those messages containing the comment ‘IFPS REROUTE ACCEPTED’ that are submitted via
an AFTN address located outside the IFPZ that has not been registered as ‘known’ in the
Environment database shall have that originator address added in an ‘AD line’ under the readdressing
function (see § Re-Addressing)
System Processing
The use of the IFPS Re-route Accepted authorisation requires that the message originator
receive a copy of the corrected data in the operational reply message (see § ORM). For
unrecognised AFTN addresses outside the IFPZ, the IFPS shall not send any ORMs other than a
reject message. Message originators outside the IFPZ using the AFTN network to submit
messages to the IFPS for processing shall be responsible to ensure the receipt of any information
corrected under this authorisation.
Those message originators filing via the SITA network from outside the IFPZ shall automatically
receive all ORMs (see § ORM).
To ensure receipt of operational reply messages to any aircraft operator located outside the IFPZ
submitting through an AFTN address unknown in the IFPS, or routing messages through a
gateway address, it is possible to copy ORMs to the aircraft operator (see § ORM).
It is also possible to use the re-addressing function (see § Re-addressing), where the AFTN
address that requires any updated version of the flight plan is added to the ‘AD’ line of the
submitted message, but this method shall only provide a copy of the accepted message, not an
ORM.
Error Messages
None Relevant
General Procedures
Where a message submitted to the IFPS for processing contains the comment ‘IFPS REROUTE
ACCEPTED’ in the RMK sub-field (see § Item 18: Other Information) of that message, the IFPS
shall treat that comment as authorisation to manually treat that message as necessary and where
possible, taking into account the requirements laid out in the Quality of Submitted Messages (see
§ Quality of Submitted Messages) .
Where major changes to the route or flight level are necessary to allow for successful processing,
or when a re-route enters a previously untouched national airspace, it is advisable that, wherever
possible, the IFPS staff endeavour to co-ordinate the necessary changes with the message filer
prior to acknowledging the modified message, regardless of the presence of that comment.
Particular care shall be taken with military flights and flights with special status, as diplomatic
clearances could be an issue in the event of any re-routing by the IFPS staff.
Should the IFPS staff require to co-ordinate any changes carried out under the IFPS Re-route
Accepted authorisation, they shall do so by whatever practical means are available. Where the
IFPS staff determines that any necessary changes require co-ordination with the message filer,
but no practical contact is possible in order to agree any changes, then that message shall be
rejected back to the message filer. In these situations, it is recommended that the IFPS staff
communicate a possible correction to the message originator via that message originator’s AFTN
or SITA address.
The ‘IFPS Re-route Accepted’ authorisation shall not be used where an incomplete route or no
route at all is filed in the submitted message. It shall not be the responsibility of IFPS to build
routes on behalf of aircraft operators, nor shall IFPS take the comment into consideration for 8.33
kHz (see § 8.33kHz Frequency Spacing) and RVSM (see § RVSM) errors that result in a rerouting
requirement.
Note: Messages that contain the remark ‘IFPS Re-route Accepted’ are subject to the rejection
of repetitive erroneous errors procedure (see § Quality of Submitted Messages).

Reasons for getting a REJ, even though IFPS reroute.... is mentioned can be varied and picturesque, and not necessarily aplicablle in your particular case:

- Someone filling the same invalid route for the same flight and getting a correction from us on a daily/regular basis. After a while (2 days? ) it's bound to get noticed, and does not generate a lot of "good feelings"
- Someone deciding that they can't be bothered and let just throw an assortment of waypoints into 15, and let them sort it.
- We realizing that someone is trying to re-route around a ATFCM restriction and this is it's 3rd/4th attempt and we already have valid plans for ABC123A/B/C and D.
- You just spent 15 minutes fixing a FPL with multiple route/RAD errors. 10 minutes later you get the same FPL. What? Look into it, and you find that the AO decided to leave earlier, canceled and refilled, but never took into consideration the corrected route, and refiled the original crappy one.

Any of the above will get you a dry REJ, without even the courtesy of a phone call.

Yes, it can be a huge pain in the back to get a valid route in Europe these days, then again you would be surprised how often I hear, from Ops people worldwide, -"RAD? Wazztat?".
A good percentage of the people in the IFPS bussiness used to be Opsbods in their former life, and they know perfectlly well how messy it can get out there so we do try very hard to correct as many as possible. Sometimes when were going at high gear, something for anytime latter than today, might get a REJ just because we need the time to fix the ones that want to leave in 3 hours.
For all thats worth, when you're running out of ideas on what route might work give us a call. It will probably save us both time and work.
Then again, don't call 2 minutes after you receive the MAN...


rgds

[Flight Data]

That text looks a little familiar, Routechecker.....

Not a lot to add to what has already been said, but to illustrate the extremes IFPS receives, several years ago, I got a flight plan for a bizjet leaving Helsinki for the Canaries, with a route filed as DCT, and nothing else, plus the IFPS Reroute Accepted comment. A straight reject for several reasons:
- no effort at all had been put into finding a route
- I had no idea what states that flight had permissions to overfly or not
- IFPS is not a free flight planning agency, it is a flight plan distribution service designed primarily to support the flow management in Europe.

I realise that this is a rather extreme example, but it's useful to show the variety of quality in flight plans received in IFPS. The huge majority are pretty good, but with flight plans and associated messages being received from all over the world, there is quite a large number of very poor standard messages coming in to IFPS all the time. As a result, the IFPS staff can get a little jaded from time to time, and crack down on what is reasonable to accept and what is not, so the REJ rate goes up. Tie that in with an on-going exercise to improve the quality of messages submitted to IFPS, and the picture becomes clearer as to why you get REJ messages.
Also, don't forget that it is the responsibility of the aircraft operator to submit a correct flight plan, but that is definitely not easy in European airspace these days, so some assistance from IFPS is usually available.

As Routechecker says, corrections are made on a fairly discretionary basis overall, but all corrections are subject to how busy IFPS is. If there is a large number of invalid messages waiting for correction or rejection, then if the IFPS staff are spending time sorting out each problem, there will be an increasing time penalty unfairly imposed on invalid messages filed later, so fairer to all if IFPS rejects more messages.

[niknak]

Regardless of what is in field 18 of any IFR FPL, we always add "RMK/IFPS re route accepted - request re route advice if necessary"

When a re route is necessary I've never known them not help out with a new route, it's a very helpful.

Thinking about it, IFPS are the people who have up to the minute information on optimum routings, so perhaps there could be a way of making it standard procedure when a FPL is rejected for the IFPS computer to automatically issue the re route.

It would save everyone a lot of time and headaches.

[crjlover]

Pls can you explain this better:

- We realizing that someone is trying to re-route around a ATFCM restriction and this is it's 3rd/4th attempt and we already have valid plans for ABC123A/B/C and D.

Are you reffering to the reroute proposed by AIM??

[routechecker]

That text looks a little familiar, Routechecker.....

It should mate, you wrote it

Pls can you explain this better:

- We realizing that someone is trying to re-route around a ATFCM restriction and this is it's 3rd/4th attempt and we already have valid plans for ABC123A/B/C and D.

Are you reffering to the reroute proposed by AIM??

No, I'm talking about what is commonly known as ghost flight plans e.g.
-ABC123, regulated flight, with company route A, 0100 hour delay.
-AO files ABC123A, same airframe, filed with company route B to try for a better CTOT, but without cancelling ABC123. This one gets 50 minutes delay.
-AO files ABC123B, same airframe, filed with company route C to try for a better CTOT........
........ and the process continues ad nauseum until an "acceptable" CTOT arrives, and of course penalizing everybody else in the process.
The most outrageous one I've ever seen was a staggering 12 FPLs for the same aircraft, with a variety of routes, levels and EOBT's.

rgds

[30W]

RouteChecker,

A mere pilot here, so NOT a flt plan expert - we have Ops departments who deal with it. But from as users perspective - if the wonderful system gave the operator 'less delay' alternatives as an automatic option (which can then be balanced cost/time/fuel wise by the operator concerned), and accepted or rejected by the appropriate Ops departmnent, then perhaps they wouldn't have to 'ghost' the system trying to reduce their delays.

There are huge implications to running delays - cost, PR (delays are published VERY publicly these days), crew hours complications etc. I don't see why companies are at fault for TRYING to reduce them. I do however agree that many flight plans for the same flight are not acceptable. The need to 'ghost' one however obviously is - but operators MUST ensure that only one is there and either the original or the ghost is cancelled immediately the delay balance on the alternative route is decided.

I agree with flow - I have been present at an ACC when serious overload has occured, and seen the horrific dangerous mess it created.

Bottom line is if the system software is good enough to offer 'less delay choice' then operators wouldn't stab in the dark trying to establish better alternatives.

30W

[routechecker]

if the wonderful system gave the operator 'less delay' alternatives as an automatic option (which can then be balanced cost/time/fuel wise by the operator concerned), and accepted or rejected by the appropriate Ops departmnent, then perhaps they wouldn't have to 'ghost' the system trying to reduce their delays.

No automatic rerouting option exists, even though the AOWIR option in way some fills that role. However for more detail on that we need someone from across the corridor; if flowman or someone else from FMO is around, you wanna help out with this one?

There are huge implications to running delays - cost, PR (delays are published VERY publicly these days), crew hours complications etc. I don't see why companies are at fault for TRYING to reduce them. I do however agree that many flight plans for the same flight are not acceptable. The need to 'ghost' one however obviously is - but operators MUST ensure that only one is there and either the original or the ghost is cancelled immediately the delay balance on the alternative route is decided.

I know how/why/when it happens. Been there, done that, got the t-shirt (then got smart and left the job in Airline Ops ).
My rant on the original post was about people clogging up the system with fictional data that justs sit there, making a bad situation worse for themselfs and others.

Bottom line is if the system software is good enough to offer 'less delay choice' then operators wouldn't stab in the dark trying to establish better alternatives.

Bottom line is if the automated systems were good enough to fly the aircraft in all situations then airlines wouldn't have to spend all that money paying you guys to sit on the pointy end of the aluminium tubes .
DO NOT crucify me. That was a, feeble I grant you, attemp at being funny
New systems are in the works, and will eventually come about. In the mean time we all have to live with what we've got.
Which incidently is A LOT better than what everybody had 15 years ago.

[flowman]

30W

"if the wonderful system gave the operator 'less delay' alternatives as an automatic option"

There are 28000+ flight plans/ RPLs filed every day.
It is impossible to offer a least delay alternative to every one of them. The situation is fluid.

e.g. There may be one free slot on an "altenative" route. Say ten delayed flights can refile on that route. The least delay option may work for one of them but for the remaining nine the alternative route could quite possibly give more delay.
Also, just because a block of airspace is not regulated does not mean there is spare capacity. One or two re-routeings could trigger the need for regulation and produce delays.

It's a balancing act and we do the balancing. We try to match available capacity with the traffic demand. If re-routeings are available and prudent we will generally offer them.

I concede that there are limitations and some quite major faults with our re-routeing tools but even these can be overcome if the benefits are worth the sometimes considerable effort. In the near future Flow Management and IFPS will be working in the same room. This should improve our ability to deliver more re-routeing options and an improved flight planning service, but as you can see from the posts above IFPUs job is far from being a simple matter of just finding a different route and firing off replies.

flowman

[plans123]

Thanks for that Flowman, I think its always good to hear it straight from the horses mouth.

I've always found IFPS Brussels and Paris vey helpful if i'm having trouble getting an albert through the maze that is Europe at 240.

[White Hart]

Routechecker, FlightData, Flowman

thanks very much for the detailed response. I have now printed it all out in readiness for my next FBU shift - all operators will receive a copy with their rejected FPLs! (only joking!)

I was wondering - if you are a small operator (bizjet company, perhaps?) does this go against you when there are route planning restrictions and subsequent delays. Do the Big Guys get given any priority when the refile/reroute options are being advised, or is it first come - first served?

[PPRuNe Radar]

Having seen the fall out from Glopespan this morning on our inputs to NAS:

GSM448

then GSM448A x2
then GSM 448B x2
then GSM 448Q x 2

all active at one point or another ..... for the same airframe.

All I can say is we will get you ...... one day, even if I have to do it myself

Must be really a proud thing ... using 7 slots for one aircraft .. to&&ers

[halo]

I see I am not the only one to get frustrated every now and again

[flowman]

White Hart

...erm, back to your question.
It's first come first served.

flowman

[Bigears]

From my perspective, as an inputter of FPLs at an ACC, what we receive from IFPS is sometimes leaving a lot to be desired- I used to get annoyed and phone them up, until it was explained that only flights that the computer rejects are looked at. Therefore, it is possible to file a bad routeing (from my perspective) and have it accepted!

I amend the route, which may be due to bad routing (longer/through active danger area/wrong way etc) and put a message that shows to the airfield/sector what has been filed- leaving it up to the airfield/sector and pilot to sort out. (NB. We're talking the UK portion of the route here).

If I'm busy, it takes too long to phone IFPS and for them to look at the route. contact the operator and get a new route.

If its a UK Operator, and I have the time, I'll phone them up myself and suggest they refile (with a suggested route) and why. (Nothing against non-UK operators, probably won't have their phone number and its a costlier call!).

So, if you're lucky, you'll get a shorter, safer route that causes less pain to the control sectors, and if unlucky, get a longer safer route- but then you should have checked things like danger area activity first!

[Flight Data]

Bigears - a very good point that seems regularly missed when dealing with IFPS. IFPS only ever applies those routing requirements, restrictions and availability that are supplied by the member states; IFPS never puts in something like that which has not been requested by a state, so the quality received in ACCs is pretty much a direct reflection of what has been given by that ACC to IFPS. OK, there are instances where IFPS gets things wrong, but that's often in data processing, and not infrequently. However, in most cases, IFPS is doing what it has been told to do, and that's one of the main reasons why you get so many routes that pass automatically, but are unacceptable for the ACC.
I'm not trying to start a witch-hunt here, but I think it's worth highlighting the issue to raise awareness of it. Fortunately or unfortunately, according to your perspective, IFPS is a focal point of IFR/GAT flight data in Europe, and that automatically makes it the bad guy whenever something is seen as unacceptable, whatever that may be, and often regardless of logic. This then has a tendency to divert attention from where the real problem lies, as IFPS is automatically considered at fault.

For everybody interacting with IFPS at any level, you might be interested to know that there is a new IFPS User manual planned for publication around the end of March which will provide a great deal more information on how IFPS works. It combines the internal operations manual with the current external users manual, so there is going to be a great deal more transparency in what happens. The text given by Routechecker in his first post here is a copy of a part of the draft version. This new manual may not be to everybody's liking, as it states pretty clearly the responsibilities are of external users of the system, and that will most definitely mean considerably more work for some users who currently tend to make 'optimum use' of IFPS, as they will have to start taking more responsibility for their actions. If you're interested, it's all part of the EU's Single European Sky project, where the Initial Flight Plan concept requires everybody to have clearly defined roles and responsibilities.

Hope this all makes some sort of sense, but I'm rattling this off in a bit of a hurry, so apologies if it loses sense at all.

[White Hart]

flowman

first come - first served seems the fairest way, so I'm glad that this applies - avoids any accusations of Operator favouritism!

Taking the thread a touch to one side (but still relevant to it!)...

Can IFPS deal with flight plans received via the Internet, (as opposed to AFTN, SITA or fax) and more importantly, is there such a scheme in operation at IFPS now?

[routechecker]

Can IFPS deal with flight plans received via the Internet, (as opposed to AFTN, SITA or fax) and more importantly, is there such a scheme in operation at IFPS now?

Nope, strictly AFTN or SITA only.
There is talk about implementing message filing via internet sometime in the future.....

rgds