Wireless Access and Terminal Mobility in CORBA RFP

1
Wireless Access and Terminal Mobility in CORBA RFP

• Joint Revised Submission
• Borland, Highlander, Nokia, Vertel
• Supported by Sonera and University of Helsinki

2
OMG documents

• Submission telecom/2001-02-01
• IDL telecom/2001-02-02
• erratas telecom/2001-02-04 and 05

Contact persons Ke Jin, Borland Jon Currey,
Highlander Kimmo Raatikainen, Nokia Shahzad
Aslam-Mir (Sam), Vertel Jouni Korhonen,
Sonera Kimmo Raatikainen, University of Helsinki
Other active contributors Ken Black,
Highlander Jari Länsiö, Nokia Jaakko Kangasharju,
University of Helsinki
3
Presentation Outline

• Design Principles
• Architectural Framework
• Key components
• GIOP Tunneling Protocols
• Handoff
• Mobility Event Notifications

4
Design Principles

• transparency
• clients invoking targets on terminals do not need
  to be aware of this specification
• targets invoked by clients on terminals do not
  need to be aware of this specification
• simplicity
• specify minimum functionality for to support
  mobile CORBA applications
• some mandatory requirements of the RFP not
  addressed
• design heavily affected by the DOLMEN experiences
  and prototype
• University of Helsinki has implemented most of
  this specification as an extension to MICO

5
Mandatory Requirments 1/3

• Architectural framework
• The Architectural Framework does not define the
  concept of mobility domain as requested in the
  RFP. Instead, concepts of home domain, visited
  domain, and terminal domain are used.
• GIOP mapping onto Internet transport protocol
  (TCP or UDP) over wireless links
• The response does not define a GIOP mapping onto
  Internet transport protocol (TCP or UDP) over
  wireless links.
• Instead, the response defines how GIOP messages
  are to be tunneled between bridges. This was
  regarded as a more elegant way of using link
  specific transport mechanisms.
• The response specifies an abstract GIOP Tunneling
  Protocol and how this protocol is run over TCP,
  UDP, and WAP Wireless Datagram Protocol (WDP).

6
Mandatory Requirements 2/3

• Mechanism that hides from CORBA clients the
  mobility of terminals on which CORBA servers are
  running
• Mobile IOR
• Mechanism for initial access to a new mobility
  domain
• An initial access mechanism is not specified
  since it was regarded too network technology and
  access provider specific to be in the scope of
  OMG.
• Mechanism for finding the necessary basic set of
  CORBA services in mobility domain
• The response specifies a simple discovery
  mechanism similar to resolving initial references
  in the ORB pseudo-interface.

7
Mandatory Requirements 3/3

• Mechanism for advertising CORBA services
  available on a mobile terminal
• The response does not propose a mechanism for
  advertising CORBA services available on a mobile
  terminal. This was regard as unnecessary.
  Instead, objects on the terminal can use either
  Naming Service or Trader Service either in the
  Home Domain or in a Visited Domain.
• Mechanism for handoff between mobility domain
• The handoff support is defined as an optional
  feature.

8
Optional Requirements

• GIOP mappings onto other wireless transport
  protocols
• Wireless/Mobility specific ES-IOP
• This response does not directly address the
  optional requirements.
• However, the proposed GIOP Tunneling Protocol
  over WAP WDP can be regarded as a response to the
  first optional requirement.

9
Issues to be discussed

• Relationship to Notification Service
  telecom/98-11-01
• Relationship to Messaging Service
  orbos/98-05-05
• Relationship to Interoperable Naming Service
  orbos/98-10-11
• This response discusses usage of Notification
  Service, Interoperable Naming Service, and
  Messaging Service in Chapter 9.
• The response specifies, as an optional feature,
  notifications of terminal mobility events.

10
Key Components

• Mobile IOR is a relocatable object reference.
• Home Location Agent keeps track of the current
  location of the mobile terminal.
• Access Bridge is the network side end-point of
  the GIOP tunnel. It encapsulates GIOP messages to
  the Terminal Bridge and decapsulates the GIOP
  messages from the Terminal Bridge.
• Terminal Bridge is the terminal side end-point of
  the GIOP tunnel.
• The GIOP tunnel is the means to transmit GIOP
  messages between the Terminal Bridge and the
  Access Bridge.
• The abstract GIOP Tunneling Protocol (GTP)
  defines how GIOP messages are presented. It also
  specifies necessary control messages.
• Three concrete tunneling protocols are specified
  TCP, UDP, and WAP WDP tunneling

11
Mobility Architecture
12
Mobile IOR

• Mobile IOR hides the mobility of the terminal on
  which the target object is located
• Mobile IOR is transparent to clients, i.e. ORB on
  which the invoking client runs does not need to
  be aware this specification
• Mobile IOR contains
• at least one IIOP profile (TAG_INTERNET_IOP)
• exactly one Mobile Terminal profile
  (TAG_MOBILE_TERMINAL_IOP)
• IIOP profile in Mobile IOR identifies the Home
  Location Agent or the current Access Bridge (not
  the target object)
• LOCATION_FORWARD mechanism is used to route
  requests from an old Access Bridge or from the
  HLA to the current Access Bridge

13
Mobile Terminal Profile

• struct ProfileBody
• Version mior_version // version of Mobile IOR
• octet reserved
• TerminalId terminal_id // unique terminal
  identifier
• TerminalObjectKey terminal_object_key //
  object_key on terminal
• sequence ltIOPTaggedComponentgt components

TAG_HOME_LOCATION_INFO Component identifies the
Home Location Agent (at most one instance of this
component) contains encapsulated IOR of the Home
Location Agent
14
Mobile Object Key

• Home Location Agent and Access Bidges need full
  IOR of the target object at the mobile terminal
• In GIOP 1.2, the HLA or the Access Bridge can
  request the client to send full IOR (the Reply
  Status NEEDS_ADDRESSING_MODE)
• In GIOP 1.0 and 1.1, Object Key is the only way
  to address the target object.
• Mobile Object Key format encapsulation of
• four octets containing ASCII values of M, I,
  O, R followed by
• struct MobileObjectKey
• Version mior_version
• octet reserved
• TerminalId terminal_id // octet sequence
• TerminalObjectKey terminal_object_key //octet
  sequence

15
Home Location Agent

• update_location(in terminal_id, in
  new_access_bridge)
• An Access Bridge uses this operation to inform
  the HLA that it is going to take care of the
  terminal
• query_location(in terminal_id, out
  current_access_bridge)
• An Access Bridge can use this operation to learn
  the current Access Bridge of a terminal that was
  once attached to it
• Discovery of object references in the Home Domain
• list_initial_services()
• resolve_initial_references(in identifier)
• used by CORBA applications running on the terminal

16
Access Bridge

• Discovery of object references in the Visited
  Domain
• list_initial_services()
• resolve_initial_references(in identifier)
• used by CORBA applications running on the
  terminal
• Query
• terminal_attached(in terminal_id)
• used by the HLA or an Access Bridge to check
  whether or not the terminal is still attached to
  the Access Bridge
• get_address_info(out transport_address_list)
• used by the HLA or an Access Bridge to get
  transport addresses that a Terminal Bridge can
  use for GIOP tunnels

17
GIOP Tunneling
18
Tunneling Overview

• A means to transfer GIOP and tunnel control
  messages between a Terminal Bridge and an Access
  Bridge.
• There is only ever one GIOP tunnel between a
  given Terminal Bridge and Access Bridge.
• A graceful handoff behavior is defined so that
  the Terminal Bridge can seamlessly transfer the
  GIOP Tunnel from the current Access Bridge to a
  new one.
• If the terminal can have simultaneous transport
  connectivity to two Access Bridges, then the
  Terminal Bridge creates a new tunnel to a new
  Access Bridge before shutting down the tunnel to
  the previous Access Bridge.
• A tunnel is shared by all GIOP connections to and
  from the terminal it is associated with.

19
Protocol Stacks in GIOP Tunneling
Access Bridge ORB
peer ORB
Terminal ORB
20
GIOP Tunneling Protocol 1/2

• The tunneling protocol allows multiplexing
  between the GIOP connections.
• The GIOP Tunneling Protocol (GTP) is an abstract,
  transport-independent protocol.
• It needs to be mapped onto one or more concrete
  protocols.
• GTP assumes that the underlying concrete
  tunneling protocol, that is the adaption layer
  between the GTP and a transport protocol,
  provides the same reliability and ordered
  delivery of messages assumed by the GIOP.
• This specification defines three concrete
  tunneling protocols TCP Tunneling, UDP
  Tunneling, and WAP WDP Tunneling.

21
GIOP Tunneling Protocol 2/2

• GTP defines message formats
• for establishing, releasing, and re-establishing
  (recovery) the tunnel
• for transmitting and forwarding GIOP messages
• for forwarding GTP messages to and from old
  Access Bridges
• for establishing and releasing GIOP connections
  through the Access Bridge
• Since handoff is an optional feature, GTP has two
  versions
• 1.0 no handoff support 2.0 handoff supported

22
GTP Message Structure

• struct GTPHeader
• unsigned short seq_no
• unsigned short last_seq_no_received
• octet gtp_msg_type
• octet flags
• unsigned short content_length

23
GTP Messages 1/2

• IdleSync
• to ack GTP messages when acks connot be
  piggybacked
• EstablishTunnelRequest
• to establish or to re-establish a GIOP tunnel
  (sent only by Terminal Bridge)
• EstablishTunnelReply
• to accept or to reject tunnel establishment (sent
  only by Access Bridge)
• ReleaseTunnelRequest
• to release the GIOP tunnel
• ReleaseTunnelReply
• to acknowledge the tunnel release

• OpenConnectionRequest
• to open a GIOP connection to the target
• OpenConnectionReply
• to acknowledge GIOP connection open
• CloseConnectionRequest
• to close GIOP connection(s)
• CloseConnectionReply
• to acknowledge GIOP connection close
• ConnectionCloseIndication
• to inform closure of GIOP connection(s)
• Error
• forced shutdown

24
GTP Messages 2/2

• HandoffTunnelRequest (only in GTP 2.0)
• to give the transport addresses of a new Access
  Bridge in network initiated handoff (Access
  Bridge only)
• HandoffTunnelReplyCompleted (only in GTP 2.0)
• to report the handoff status to the sender of
  HandoffTunnelRequest (Terminal Bridge only)

• GIOPData
• to send a GIOP message over the GIOP Tunnel
• GIOPDataReply
• to acknowledge the delivery of a GIOP message to
  the target
• GTPForward (only in GTP 2.0)
• to relay a GTP message to/from an old Access
  Bridge
• GTPForwardReply (only in GTP 2.0)
• to acknowledge a relayed GTP message

25
TCP Tunneling

• GTP messages are transmitted in a TCP byte stream
  without any padding or message boundary markers
• Address format
• string containing the ltip_addressgt, , and
  port_number
• ltip_addressgt is either DNS name of the host or an
  IP address in dotted decimal notation

26
UDP Tunneling

• GTP messages are transmitted using a framing
  protocol, called UDP Tunneling Protocol, in the
  payload of UDP datagrams.
• Address format
• string containing ltip_addressgtltport_numbergt
• ltip_addressgt is an IP address in dotted decimal
  notation
• The UDP Tunneling Protocol (UTP) provides the
  reliability and ordered delivery of messages
  assumed by the GIOP Tunneling Protocol
• UTP assumes that it does not get corrupted data.
• UTP defines encapsulation of GTP messages.
• It also supports segmentation and re-assembly of
  GTP messages and selective acknowledgements.

27
Structure of UTP Message
28
UTP Header

• The UTP header is four bytes
• UTP Sequence Number (unsigned short)
• Number of UTP chunks (unsigned short) in the UTP
  message.
• The network byte order (that is Big-Endian) is
  always used to express numeric values.
• Strings are always in 8-bit ANSI ASCII format.

29
UTP Chunk

• Type-Flags-Length-Value field
• The Type field is one octet.
• If present the Flags field is one octet. It is
  used to denote fragmentation.
• The Length field is 0-2 octets telling the length
  of the Value field in the network byte order if
  the Value field can be of variable length.
• The Value field if present contains the payload
  of a UTP chunk.
• The UTP chunks are
• InitialAccessRequest
• InitialAccessReply
• Pause (no other fields) sender will discard
  forthcoming datagrams
• Resume (no other fields) sender will again
  accept datagrams
• Acknowledge
• GTPData Value field contains a GTP message or a
  part of it

30
Initial Access Request

• Source Terminal Bridge
• Length field 2 octets (unsigned short)
• Value field
• struct InitialAccessRequestChunk
• sequenceltoctetgt cookie
• string terminal_bridge_udp_address
• cookie will be returned in the reply

31
Initial Access Reply

• Source Access Bridge
• Length field 2 octets (unsigned short)
• Value field
• struct InitialAccessReplyChunk
• sequenceltoctetgt cookie
• string access_bridge_udp_address
• cookie must be the same as in the request,
  otherwise the Terminal Bridge considers the reply
  as a fake

32
Acknowledge

• No Flags field
• Length field 1 octet
• number of elements in the Value field
• Value field
• first unsigned short highest UTP seqno received
  in order
• rest of unsigned shorts (if any) other UTP
  seqnos received

33
WAP Tunneling 1/2

• The WAP Tunneling Protocol (WAP-TP) uses the
  Wireless Application Protocol to transmit GTP
  messages between Terminal and Access Bridge.
• The main design principle in WAP-TP has been
  simplicity of the implementation.
• It is assumed that WAP-TP will be used in small
  embedded devices with limited capabilities.
• WAP-TP ensures that the assumptions stated by GTP
  are no violated, specifically that no corrupted
  data is delivered and that the order of GTP
  messages is preserved.
• WAP-TP uses the Wireless Datagram Protocol (WDP)
  of the WAP specification.
• It operates above the data capable bearer
  services supported by multiple network types.

34
WAP Tunneling 2/2

• GTP messages are transmitted in Invoke PDUs of
  WAP WDP, one GTP message in one WDP datagram.
• Since WDP datagrams are not guaranteed to
  preserve order, so WAP-TP MUST delay the delivery
  of GTP messages that have higher sequence number
  than expected.
• The WDP supports several address types including
• IP addresses (both IPv4 and IPv6),
• MSISD (a telephone number) in various flavors
  (IS_637, ANSI_136, GSM, CDMA, iDEN, FLEX, TETRA),
• GSM_Service_Code, TETRA_ISI, and Mobitex MAN.
• struct WDPAddressFormat
• octet wdp_version // mostly 0x00, depends on
  bearer see WDP
• octet wap_assigned_number // see WDP, Appendix
  C
• unsigned short wap_port // Port number
• string address

35
Handoff
36
Handoff Procedures

• Handoff support is an optional feature
• Three different procedures
• Network initiated handoff
• Terminal initiated handoff
• Access Recovery

37
Network Initiated Handoff
38
Terminal Initiated Handoff
39
Access Recovery
40
GTP Message Forwarding

• When an old Access Bridge wants to send a GIOP
  message to the terminal, it encapsulates it to a
  GTP message and invokes
• void gtp_to_terminal ( // old Access Bridge -gt
  current Access Bridge
• in TerminalId terminal_id, in AccessBridge
  old_access_bridge,
• in unsigned long gtp_message_id, in
  GTPEncapsulation gtp_message
• ) raises (TerminalNotHere)
• When the current Access Bridge receives a GTP
  message from the Terminal Bridge targeted to an
  old Access Bridge, the current Access Bridge
  invokes
• void gtp_from_terminal ( // current Access Bridge
  -gt old Access Bridge
• in TerminalId terminal_id,
• in unsigned long gtp_message_id,
• in GTPEncapsulation gtp_message
• )

41
Terminal Tracking

• An old Access Bridge needs to know the current
  Access Bridge of the terminal as long as the
  Terminal Bridge has open GIOP connections thru
  the old Access Bridge.
• Access Bridge from which the terminal is moving
  informs all old Access Bridge still interested in
  movements of the terminal
• void handoff_notice (in TerminalId terminal_id,
  in AccessBridge new_access_bridge)
• If an old Access Bridge is still interested to be
  informed of terminal movements, it must invoke
• void subscribe_handoff_notice (in TerminalId
  terminal_id, in AccessBridge interested_access_bri
  dge) raises (TerminalNotHere)
• at the new Access Bridge.

42
Mobility Event Notifications
43
Usage of Mobility Event Notifications

• Terminal
• Mobility aware applications to resolve visited
  domain references after a handoff
• Access Network
• management and monitoring applications

44
Erratas

• Primarily typos and clarifications
• Mobile Object Key
• an encapsulation
• IPv6 address is 128 bits or 16 bytes (not 32
  bytes)
• Figure 7-1 inserted
• enumeration values prefixed in GTP module
• ACCESS_ACCEPT_LOCAL inserted to
  EstablishTunnelReply for homeless terminals
• Special note in OpenConnectionRequest
• Access Bridge may use GIOPTargetAddress type as
  CORBAObject type

45
Conclusions

• Revised submission is mature
• Finalization Task Force can handle editorial
  changes needed
• Submitters are ready to vote-to-vote and to vote