Konstantin Georgokitsos (kgeorgok@rcs.sel.de) writes:
Hi Lloyd,
I was skipping through your paper on Integration of UMTS and B-ISDN - it is possible or desirable? and read at the end of section Alternatives for integrating UMTS with other networks the following:
These modifications only concern high-level B-ISDN signalling protocols, and do not alter the transport mechanisms. The underlying ATM layers, including the ATM adaptation layer (AAL) are unaffected by this.
This is not quite true. It's correct that all your sources you mention are more or less telling you this, but this is basically due to the fact that the RACE Monet project had long neglected the B-ISDN part of the equation and was instead fervently investigating the mobility control separation into IN. There is a public RACE Deliverable (R2066/GA3/SEL/DS/P/087/b1) from last year where the workpackage GA3 (which I was leading) of Monet made first close examination of the topic. This year (the last project year) the studies were deepened, but as yet there are no public reports. The next occasion when you can get more information will be at the RACE Mobile Summit in November in Portugal, then in December all Monet deliverables will be made available to the public.
Just to give you a hint why the ATM level might be influenced:
The major impact comes from a requirement where the user should not be
able to notice a handover (usually, but perhaps incorrectly referred to
as "seamless" handover). There you will have problems with synchronisation
which will not be solvable above the ATM layer. Also, if you are applying
macro diversity and you have a combiner in the ATM network, you will have
to examine single cells from both paths to decide on the quality.
You also mention that handover could be performed by adding and dropping a multi-call party. This solution was proposed by an ad-hoc study group of Monet last year. It is probably the last resort one can take when integrating. My opinion is that the problem of handover in the end must be solved on a deeper level, even if it means that you have a bit more impact on B-ISDN or ATM. I'm sorry to be very sketchy, but I am not in this exact subject anymore, and, after all, solutions are quite in limbo and unpublishable right now.
Cheers, Konstantin
Lloyd Wood
(L.Wood@surrey.ac.uk) replies:
Hi Konstantin,
Thankyou for the feedback. GA3 is news to me.
You're right in that all the sources I read for the paper avoided
discussing ATM in any depth and did not talk about modifications to
the transport layers. I simply couldn't find anything that did, and I
recall coming away with the impression that no-one wanted to even start
thinking about changing ATM, and that they preferred instead to just
add functionality at a higher level as the easier, standards-focused,
option, however wise that may be.
I'm somewhat out of the ATM field at the moment in that I'm doing very
elementary analysis and simulation of satellite constellation networks,
but if I can build up realistic enough simulations, simulating running
ATM over intersatellite links and addressing changeover - e.g. selecting
the 'best' satellite from the ground to minimise changeover times and
impact on the virtual circuit - and other mobility issues
such as synchronisation will begin to appear, so I'm quite interested
in picking up ATM tidbits and staying abreast of the field any way I can.
Thanks,
L.
PS: Why are we Engineers so fascinated by Star Trek? It must be the communicators, I think!
PS: I always thought it to be the attraction of the crew's ability to solve difficult engineering problems in a few minutes, with short or no committee meetings, functioning equipment, no visible paperwork, and NO BUDGET LIMITS.
Ah, THAT's why it's called science fiction.
That's what we engineers dream of, right?
I'm not sure. Sounds like if all this is met anybody could solve these problems. And what would we engineers do then?