Wireless Access and Terminal Mobility Avatar
  1. OMG Specification

Wireless Access and Terminal Mobility — All Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
WATM11-2 Issue/Telecom Wireless CORBA: Retransmissions in UTP WATM 1.0 WATM 1.1 Resolved closed
WATM11-3 Issue/Telecom Wireless CORBA: Sequence numbers of UTP messages WATM 1.0 WATM 1.1 Resolved closed
WATM11-1 Issue/Telecom Wireless CORBA: Closing UTP Communication Session WATM 1.0 WATM 1.1 Resolved closed
WATM-13 gtp_from_terminal should be able to raise an exception WATM 1.0b1 WATM 1.0 Resolved closed
WATM-11 Issue for Telecom Wireless FTF -- EDITORIAL WATM 1.0b1 WATM 1.0 Resolved closed
WATM-12 GTPForwardReply needs to be forwardable WATM 1.0b1 WATM 1.0 Resolved closed
WATM-8 A possible race condition with location updates during recovery WATM 1.0b1 WATM 1.0 Resolved closed
WATM-9 Request consistency in OpenConnectionRequest WATM 1.0b1 WATM 1.0 Resolved closed
WATM-7 Mobile IOR version number needs to be defined WATM 1.0b1 WATM 1.0 Resolved closed
WATM-10 Specify handoff status report of Access Bridge on NO_MAKE_BEFORE_BREAK WATM 1.0b1 WATM 1.0 Resolved closed
WATM-6 If acknowledgement is already done is the GIOPDataReply message superfluous WATM 1.0b1 WATM 1.0 Resolved closed
WATM-5 Recovery_request needs a failure indication WATM 1.0b1 WATM 1.0 Resolved closed
WATM-4 Separate different conformance levels by Level numbers WATM 1.0b1 WATM 1.0 Resolved closed
WATM-3 New Access Bridge cannot distinguish between different kinds of handoff WATM 1.0b1 WATM 1.0 Resolved closed
WATM-2 Connection ids in OpenConnection may conflict WATM 1.0b1 WATM 1.0 Resolved closed
WATM-1 Request rearrangement of GTPHeader WATM 1.0b1 WATM 1.0 Resolved closed

Issues Descriptions

Issue/Telecom Wireless CORBA: Retransmissions in UTP

  • Key: WATM11-2
  • Legacy Issue Number: 7610
  • Status: closed  
  • Source: Nokia ( Kimmo Raatikainen)
  • Summary:

    The section 7.4 'UDP Tunneling' does not say anything about retransmissions. This may lead to implementations that are either suboptimal in bandwidth consumption or incompatible.

    Resolution:
    Give recommendations about retransmission policy similar to TCP's NewReno-SACK.

    Revised text:

    Add a new subsection 'Retransmission Policy' before the subsection 7.4.2 'Fragmentation':

    Retransmissions in UDP Tunneling Protocol SHOULD be controled by a policy based on an estimate for the Round Trip Time (RTT) such as NewReno-SACK in TCP [RFC nnnn]. The Retransmission TimeOut (RTO) MUST be at least the estimated RTT.

    Add the following note at the end of subsection 7.4.6 'Resume':

    Note: The Resume chunk SHOULD be included in each UTP message until the sender has received an acknowledgement for a message containing a Resume chunk.

  • Reported: WATM 1.0 — Mon, 2 Aug 2004 04:00 GMT
  • Disposition: Resolved — WATM 1.1
  • Disposition Summary:

    No Data Available

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

Issue/Telecom Wireless CORBA: Sequence numbers of UTP messages

  • Key: WATM11-3
  • Legacy Issue Number: 7611
  • Status: closed  
  • Source: Nokia ( Kimmo Raatikainen)
  • Summary:

    Usage of sequence numbers in UDP Tunneling Protocol messages in section 7.4 needs refinements.
    We have found the following two problems:
    1) If the first sequence number is arbitrary, then the receiver must examine the playload before it can detect whether or not the beginning of the message sequence is received.
    2) If UTP messages containing only Acknowledge chunck are acknowledged, then we will have an infinite loop of ackning acks.

    Resolution:
    1) Start sequence numbers always from 0x0001.
    2) Reserve sequence number 0x0000 for UTP messages that are not to be acknowledged (messages that only contain Acknowledge and/or Pause chunk).

    Received text:
    Add a new subsection 'Sequence Numberging' after the subsection 7.4.1 'UDP Tunneling Protocol':

    Each communication session must start sequence numbering from 0x0001. In other words the UTP message containing the InitialAccessRequest chunk (or its first fragment) and the associated reply containing the InitialAccessReply chunk (or its first fragment) MUST have UTP Sequence Number 0x0001.

    The sequence number counting follows the usual modulo arithmetic with the exception that the sequence number 0x0001 follows the sequence number 0xFFFF.

    The UTP Sequence Number 0x0000 is reserved for UTP messages that only contain the Acknowledge chunk and/or the Pause chunk. These messages MUST NOT be acknowledged.

    Add the following note at the end of subsections 7.4.3 'InitialAccessRequest' and 7.4.4 'InitialAccessReply':

    Note: UTP message containing this chunk (or its first fragment) MUST have sequence number 0x0001.

    Add the following two notes at the end of subsection 7.4.5 'Pause':

    Note 1: If the UTP message contains only the Pause chunk (with or without the Acknowledge chunk), then the UTP Sequence Number MUST be 0x0000. The receiver SHOULD NOT acknowledge such a message.

    Note 2: After sending the Pause chunk, the sender SHOULD reply to each arriving message by a UTP message containing the Pause chunk. The UTP message MAY also contain ACknowledge and/or GTPData chunks.

    Add the following note at the end of subsection 7.4.7 'Acknowledge':

    Note: If the UTP message contains only the Acknowledge chunk (with or without the Pause chunk), then the UTP Sequence Number MUST be 0x0000. The receiver SHOULD NOT acknowledge such a message.

  • Reported: WATM 1.0 — Mon, 2 Aug 2004 04:00 GMT
  • Disposition: Resolved — WATM 1.1
  • Disposition Summary:

    No Data Available

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

Issue/Telecom Wireless CORBA: Closing UTP Communication Session

  • Key: WATM11-1
  • Legacy Issue Number: 7609
  • Status: closed  
  • Source: Nokia ( Kimmo Raatikainen)
  • Summary:

    There is no way in the current specification to gracefully close a communication session. This is not a problem, but may complicate recovery from communication failures.

    Resolution: Add CloseRequest, CloseReply and CloseIndication chunks. CloseRequest/CloseReply pair of chunks allows negotiated closing of the UTP communication session. CloseIndition chunk allows a bridge to inform its peer bridge that it is going to close the UTP communication session.

    Revised text:
    Add the following three descriptions of UTP chunks at the end of subsection 7.4.1 'UDP Tunneling Protocol':
    7. CloseRequest: sent by the Terminal or Access Bridge. No Flags, Lenght, and Value field.
    8. CloseReply: sent by the Terminal or Access Bridge. No Flags, Lenght, and Value field.
    9. CloseIndication: sent by the Terminal or Access Bridge. No Flags, Lenght, and Value field.

    Add the following three subsections at the end of section 7.4 'UDP Tunneling':

    Close Request

    The chunk Type is 0x07. The chunk does not have any other fields.

    The chunk can be sent either by the Terminal Bridge or by the Access Bridge.

    The bridge sends this chunk when it wants to close the communication session. After sending this chunk the bridge mwaits for the UTP message cointaining the CloseReply chunk. The bridge sending the CloseRequest chunk MUST process and acknowledge all UTP messages until receiving the CloseReply chunk.

    When a bridge receives the CloseRequest chunk, it SHOULD immediately retransmit all unacknowledged UTP messages as well as all remaining GTP messages before sending the CloseReply chunk.

    CloseReply

    The chunk Type is 0x08. The chunk does not have any other fields.

    The chunk can be sent either by the Terminal Bridge or by the Access Bridge in response to the CloseRequest chunk.

    The bridge receiving the CloseRequest chunk SHOULD NOT send the CloseReply chunk before all other UTP messages have been acknowledgeged. After sending the CloseReply chunk, the bridge SHOULD wait for the acknowledgement before releasing all data structures associated with the UTP communication session.

    The bridge receiving the CloseReply chunk SHOULD acknowledge the UTP message containing the CloseReply chunk by a UTP message having sequence number 0x0000. After sending this reply the bridge can release all data structures associated to the UTP communication session.

    If a bridge receives CloseReply chunk, but it has not send the CloseRequest chunk, the bridge SHOULD send the CloseIndication chunk. See section 7.4.n 'CloseIndication'.

    CloseIndication

    The chunk Type is 0x09. The chunk does not have any other fields.

    The chunk can be sent either by the Terminal Bridge or by the Access Bridge.

    The bridge send this chunk to inform the peer bridge that it will close the communication session. The bridge MAY wait for the acknowledgement of the UTP message containing the CloseIndication chunk. In this case the bridge SHOULD discard all arriving UTP messages and response by retransmitting the UTP message containing the CloseIndication chunk. However, the bridge does not need to wait for the acknowledgement of the UTP message containing the CloseIndication chunk. It can immediately, after sending the CloseIndication chunk, release all data structures related to this communication session and stop accepting messages to the UDP port.

    When the peer bridge receives the CloseIndication chunk, it SHOULD immediately acknowledge that UTP message and stop using the UDP end-point of the peer bridge. After sending the acknowledgement, the bridge SHOULD release all data structures related to the UTP communication session.

  • Reported: WATM 1.0 — Mon, 2 Aug 2004 04:00 GMT
  • Disposition: Resolved — WATM 1.1
  • Disposition Summary:

    No Data Available

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

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

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

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

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

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

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

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

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

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