Wireless Access and Terminal Mobility Avatar
  1. OMG Specification

Wireless Access and Terminal Mobility — All Issues

  • Acronym: WATM
  • Issues Count: 13
  • Description: All Issues
Open Closed All
All Issues

Issues Descriptions

gtp_from_terminal should be able to raise an exception

  • Key: WATM-13
  • Legacy Issue Number: 4649
  • Status: closed  
  • Source: University of Helsinki ( Jaakko Kangasharju)
  • Summary:

    Currently gtp_from_terminal has no raisable exceptions. But it might
    happen that the Access Bridge has already forgotten the terminal. In
    this case it should communicate this to the invoker by raising an
    exception (UnknownTerminalId would be suitable). The invoker can then
    send a GTPForwardReply with the status FORWARD_ERROR_UNKNOWN_SENDER.

  • Reported: WATM 1.0b1 — Mon, 29 Oct 2001 05:00 GMT
  • Disposition: Resolved — WATM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:51 GMT

GTPForwardReply needs to be forwardable

  • Key: WATM-12
  • Legacy Issue Number: 4648
  • Status: closed  
  • Source: University of Helsinki ( Jaakko Kangasharju)
  • Summary:

    GTPForwardReply needs to be forwardable

    Currently GTPForwardReply (section 7.2.18) is marked not forwardable.
    But if there have been outstanding GTPForward messages when handoff
    happens, these messages cannot then be acknowledged. This situation
    is similar to the one with OpenConnection where OpenConnectionReply is
    forwardable, the reason being that outstanding requests can be
    responded to after handoff. For the same reason, GTPForwardReply
    should also be forwardable.

  • Reported: WATM 1.0b1 — Mon, 29 Oct 2001 05:00 GMT
  • Disposition: Resolved — WATM 1.0
  • Disposition Summary:

    Make GTPForwardReply forwardable

  • Updated: Fri, 6 Mar 2015 20:51 GMT

Issue for Telecom Wireless FTF -- EDITORIAL

  • Key: WATM-11
  • Legacy Issue Number: 4625
  • Status: closed  
  • Source: Nokia ( Kimmo Raatikainen)
  • Summary:

    Chapter 3.1.1.
    In paragraphs 2, 3, and wording "returning the object reference of the
    Access Bridge" is not precise enough. Instead we should say "returning the
    Mobile IOR indicating the Access Bridge".
    3rd paragraph, line 4: replace "replies" by "should reply"
    4th paragraph, line 3: replace "will reply" by "should reply"

    Chapter 3.2.1 IDL of ProfileBody
    add space between TerminalObjectKey and teminal_object_key

    Page 3-4, 2nd paragraph, line 3: replace "MobileTermial" by "MobileTerminal"

    Page 4-2, 1st line: remove "," after "new_access_bridge"

    Pages 4-2 and 4-3: replace "UnknownTermialID" by "UnknownTerminalId" (four
    times)

    Chapter 7.2
    Add at the bottom of page 7-2 paragraph: All timeout values are in seconds.

    Page 7-5: replace "MobileTeriminal" by "MobileTerminal" (two times)

    Page 7-5, last paragraph: The last two line should read as:
    "then a handoff procedure or the access recovery procedure as described in
    Section 8.2, "Network Initiated Handoff", in Section 8.3, "Terminal
    Initiated Handoff", or in Section 8.4, "Access Recovery", is carried out.

    Page 7-10, first line: replace
    "MobileTerminal::AccessBridgeTransportAddress" by
    MobileTerminal::AccessBridgeTransportAddressList"

    Page 7-15, second bullet: replace "CLOSE_REASON_RRESOURCE_CONSTRAINT" by
    "CLOSE_REASON_RESOURCE_CONSTRAINT"

    Page 7-15, third bullet: replace "CLOSE_REASON_RIDLE_CLOSED" by
    "CLOSE_REASON_IDLE_CLOSED"

    Page 7-15, fourth bullet: replace "CLOSE_REASON_RTIME_TO_LIVE_EXPIRED" by
    "CLOSE_REASON_TIME_TO_LIVE_EXPIRED"

    Chapter 7.2.17, paret Description, 2nd paragraph: replace "gtp_from
    terminal" by gtp_from_terminal"

    Chapter 7.5.1, 2nd paragraph: replcae "transmission of unreliable" by
    "unreliable transmission"

    Chapter 7.5.3, 1st paragraph: add "CDR encapsulation of" at the end of
    paragraph

    Figure 8-1: replace "location_update" by "update_location"

    Chapter 8.3.1, numbered item 5: replace "ReleaseTunnelReuqest" by
    "ReleaseTunnelRequest"

    Chapter 8.3.2, numbered item 2: replace "location_update" by
    "update_location" and "operation" not in bold

    Figure 8-2 and 8-3: replace "location_update" by "update_location"

    Chapter 8.5, last paragraph, 1st line: replace "an old Access," by "an old
    Access Bridge,"

  • Reported: WATM 1.0b1 — Tue, 23 Oct 2001 04:00 GMT
  • Disposition: Resolved — WATM 1.0
  • Disposition Summary:

    The following editorial changes should be implemented:

  • Updated: Fri, 6 Mar 2015 20:51 GMT

Request consistency in OpenConnectionRequest

  • Key: WATM-9
  • Legacy Issue Number: 4615
  • Status: closed  
  • Source: University of Helsinki ( Jaakko Kangasharju)
  • Summary:

    The OpenConnectionRequest in section 7.2.10 contains the target object
    reference. Since, in case of GIOP 1.0 or 1.1 clients, the Access
    Bridge may have only the object key, the note permits the Access
    Bridge to use GIOP::TargetAddress as this object reference. I request
    that, for consistency and simplicity of implementation, the target
    object reference in this message were always given as
    GIOP::TargetAddress, in both directions.

  • Reported: WATM 1.0b1 — Thu, 11 Oct 2001 04:00 GMT
  • Disposition: Resolved — WATM 1.0
  • Disposition Summary:

    The target object reference in the OpenConnectionRequest message to be of type GIOP::TargetAddress.

  • Updated: Fri, 6 Mar 2015 20:51 GMT

A possible race condition with location updates during recovery

  • Key: WATM-8
  • Legacy Issue Number: 4614
  • Status: closed  
  • Source: University of Helsinki ( Jaakko Kangasharju)
  • Summary:

    When a terminal loses connection to its current Access Bridge, section
    4.1 says that the Access Bridge deregisters the terminal by invoking
    update_location at the Home Location Agent giving NIL as the new
    Access Bridge reference. Assume now that the terminal is performing
    an access recovery to a new Access Bridge. It may happen that the new
    Access Bridge invokes update_location, then the old Access Bridge, not
    yet knowing about the recovery in progress, deregisters the terminal
    and only after that the new Access Bridge invokes recovery_request at
    the old Access Bridge. This sequence of events leaves the Home
    Location Agent to believe mistakenly that the terminal does not have
    an associated Access Bridge.

    A possible solution: Add a deregister() operation to the
    HomeLocationAgent interface. This operation would take as parameters
    the terminal id and the Access Bridge invoking it, and would return a
    boolean value. The Home Location Agent could then compare whether the
    invoking Access Bridge is the same as the Access Bridge it believes to
    be current. If it is, the HLA deregisters the terminal and returns
    true, otherwise the HLA does nothing and returns false. Now, from the
    return value, the invoking Access Bridge can tell whether there is an
    access recovery in progress, and if so, can prepare for it by hanging
    on to the terminal's information.

  • Reported: WATM 1.0b1 — Thu, 11 Oct 2001 04:00 GMT
  • Disposition: Resolved — WATM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:51 GMT

Mobile IOR version number needs to be defined

  • Key: WATM-7
  • Legacy Issue Number: 4613
  • Status: closed  
  • Source: University of Helsinki ( Jaakko Kangasharju)
  • Summary:

    The struct MobileTerminal::ProfileBody contains as its first member
    the version number of the profile. However, the specification does
    not say what version number is to be used. A clear-seeming solution
    would be to use the same version number as for GTP, since GTP is in a
    sense this profile's associated protocol.

  • Reported: WATM 1.0b1 — Thu, 11 Oct 2001 04:00 GMT
  • Disposition: Resolved — WATM 1.0
  • Disposition Summary:

    Specify that MIOR version is the same as the GTP version.

  • Updated: Fri, 6 Mar 2015 20:51 GMT

If acknowledgement is already done is the GIOPDataReply message superfluous

  • Key: WATM-6
  • Legacy Issue Number: 4611
  • Status: closed  
  • Source: Anonymous
  • Summary:

    This issue is for Telecom Wireless FTF regarding the current adopted
    specification dtc/2001-06-02.

    According to current specification, when peer receives GIOPData Message
    (7.2.15), it must reply with GIOPDataReply Message (7.2.16). GIOPDataReply
    can acknowledge GIOPDataMessage, or indicate one of two failures,
    DELIVERY_FAILED_INVALID_CONNECTION_ID or DELIVERY_FAILED_UNKNOWN_REASON.

    The issue is, if acknowledgement is already done in GTP level (using the
    last_seq_no_received field of GTPHeader) and errors can be expressed with
    Error Message (7.2.19), is the GIOPDataReply message superfluous?

    This is extremly important issue for us, for we are considering the use of
    very narrow band (and expensive) transports.

    For example, according the current specification (with the GIOPDataReply),
    every non-oneway method invocation requires a minumum of 4 transport level
    messages. Here's the message exhance for method invocation:

    [ Client ] [ Object ]

    client sends
    GIOP Request
    message:

    ------- #1 GIOPData -------->

    <----- #2 GIOPDataReply -----
    includes ack for #1

    object sends
    GIOP Reply
    message.

    <------- #3 GIOPData ---------

    ------ #4 GIOPDataReply ----->
    includes ack for #2 and #3

    if there's nothing
    else to send

    <------ #5 IdleSync ----------
    ack for #4

    However, without GIOPDataMessage the maximum is 3 messages and typical is 2
    messages. Here's how:

    [ Client ] [ Object ]

    client sends
    GIOP Request
    message:

    ------- #1 GIOPData -------->

    object sends
    GIOP Reply
    message.

    <------- #2 GIOPData --------
    includes ack for #2

    if there's
    nothing else
    to send

    ------ #3 IdleSync ---------->
    ack for #2

    Conclusion: We suggest that the GIOPDataReply message is removed from
    specification and the error code for the use of unknown connection ID
    (DELIVERY_FAILED_INVALID_CONNECTION_ID) is introduced to Error message.

  • Reported: WATM 1.0b1 — Tue, 9 Oct 2001 04:00 GMT
  • Disposition: Resolved — WATM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:51 GMT

Specify handoff status report of Access Bridge on NO_MAKE_BEFORE_BREAK

  • Key: WATM-10
  • Legacy Issue Number: 4616
  • Status: closed  
  • Source: University of Helsinki ( Jaakko Kangasharju)
  • Summary:

    In a network initiated handoff (section 8.2) the old Access Bridge is
    given a reference to a HandoffCallback object, to which the Access
    Bridge reports the status after handoff. However, if the terminal
    uses the alternate handoff procedure of section 8.2.5, the status that
    the Access Bridge is supposed to report is not specified. There seem
    to be two reasonable options:
    1) The Access Bridge reports NO_MAKE_BEFORE_BREAK as status
    2) The Access Bridge waits for recovery_request and reports success
    or failure according to whether recovery happens

    It needs to be specified which of these actions the Access Bridge
    takes.

  • Reported: WATM 1.0b1 — Thu, 11 Oct 2001 04:00 GMT
  • Disposition: Resolved — WATM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:51 GMT

Recovery_request needs a failure indication

  • Key: WATM-5
  • Legacy Issue Number: 4555
  • Status: closed  
  • Source: University of Helsinki ( Jaakko Kangasharju)
  • Summary:

    In Access Recovery to a new Access Bridge (section 8.4.2) the
    invocation of recovery_request at the old Access Bridge is assumed to
    succeed. However, it is possible that the old tunnel has been down
    for so long that the old Access Bridge has destroyed all information
    it has on the terminal. This would make it impossible to fill the out
    parameter of recovery_request correctly. I therefore suggest that an
    exception to signal a destroyed association (possibly TerminalNotHere)
    be added to recovery_request signature and that the new Access
    Bridge's actions when receiving this exception be specified.

  • Reported: WATM 1.0b1 — Wed, 5 Sep 2001 04:00 GMT
  • Disposition: Resolved — WATM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:51 GMT

Separate different conformance levels by Level numbers

  • Key: WATM-4
  • Legacy Issue Number: 4535
  • Status: closed  
  • Source: Nokia ( Jari Lansio)
  • Summary:

    In the current specification the different conformance options are separated
    by version numbers; version 1.0 that does not include hand-off and version
    2.o that supports hand-off.

    This can be quite confusing and the confusion is likely to multiply in the
    event that the whole specification is updated and receives new version
    number.

    My suggestion is to use similar technique as in CORBA security, where
    different conformance levels are separated, not by version numbers, but by
    Level numbers.

    I suggest that we change "Version 1.0" to "Level 0" and "Version 2.0" to
    "Level 1".

  • Reported: WATM 1.0b1 — Mon, 27 Aug 2001 04:00 GMT
  • Disposition: Resolved — WATM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:51 GMT

New Access Bridge cannot distinguish between different kinds of handoff

  • Key: WATM-3
  • Legacy Issue Number: 4422
  • Status: closed  
  • Source: University of Helsinki ( Jaakko Kangasharju)
  • Summary:

    In Terminal Initiated Handoff (section 8.3) and Access Recovery
    (section 8.4.2) the new Access Bridge needs to invoke different
    methods depending on the kind of handoff (step 4 in 8.3.2 and step 5
    in 8.4.2.2). However, it is not possible for it to make this
    distinction based on the information it has received in previous steps
    of the handoff.

    Furthermore, in Network Initiated Handoff (section 8.2) the only
    distinction for the new Access Bridge is the previous invocation of
    transport_address_request. But it is possible that the terminal could
    not establish connectivity during the handoff procedure and resorted
    to another kind of handoff later. So in this case the new Access
    Bridge misidentifies this handoff as network initiated.

    The simplest way to correct this seems to be to add an element for
    handoff type into RecoveryRequestBody (section 7.2.4). This solution
    also looks quite clean.

  • Reported: WATM 1.0b1 — Fri, 20 Jul 2001 04:00 GMT
  • Disposition: Resolved — WATM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:51 GMT

Connection ids in OpenConnection may conflict

  • Key: WATM-2
  • Legacy Issue Number: 4421
  • Status: closed  
  • Source: University of Helsinki ( Jaakko Kangasharju)
  • Summary:

    In opening a connection for GIOP data (sections 7.2.10--7.2.11) the
    receiver of a request is responsible for allocating a connection id.
    But if two OpenConnectionRequests cross each other, it might be
    possible for the same connection id to be allocated to two different
    connections. This would completely break at least one, maybe both, of
    the connections.

    The easiest way to fix this would be to allocate disjoint subsets of
    the available connection id space to Terminal and Access Bridges.
    Since this is a question of interoperability, the subsets need to be
    also mandated. A good one would be for the Access Bridge to use even
    numbers and the Terminal Bridge to use odd numbers (excluding the
    invalid 0xffffffff).

  • Reported: WATM 1.0b1 — Fri, 20 Jul 2001 04:00 GMT
  • Disposition: Resolved — WATM 1.0
  • Disposition Summary:

    Access Bridge uses even numbers and Terminal Bridge odd numbers (but not 0xFFFFFFFF).

  • Updated: Fri, 6 Mar 2015 20:51 GMT

Request rearrangement of GTPHeader

  • Key: WATM-1
  • Legacy Issue Number: 4420
  • Status: closed  
  • Source: University of Helsinki ( Jaakko Kangasharju)
  • Summary:

    In the GTP Header (section 7.2.1) there are two unsigned short members
    before the byte order flag. Processing this header correctly requires
    either processing out of order or possibly correcting already
    processed elements afterwards.

    I request that the members gtp_msg_type and flags be moved to the
    start of the header. This way the header can be processed in order
    without the need for backpatching, which is definitely simpler.

  • Reported: WATM 1.0b1 — Fri, 20 Jul 2001 04:00 GMT
  • Disposition: Resolved — WATM 1.0
  • Disposition Summary:

    see above

  • Updated: Fri, 6 Mar 2015 20:51 GMT