WO2000070824A2 - Distributed local and wide area network independent of connection media supported in networked devices, and managed by the networked devices - Google Patents

Abstract

A dynamically configurable network has data stations (3-11) and wireless protocol stations (2). A wireless protocol station and at least one data station form a local area network. Separate local area networks are connected to each other through wireless protocol stations. The wireless protocol stations and the data stations have a physical layer protocol (80-87) that sits in a physical layer, whereby the wireless protocol station has all physical layer protocols of data stations to which it currently connected to, so as to dynamically support various media. The wireless protocol stations and the data stations further have service application layer protocols that sit in service layers (110-117), and a service access point protocol in between the service layer and the physical layer. A service application layer of a data station provides a data service. Data between data stations or between a data station and a wireless protocol station are physically exchanged via a communication link using the physical layer protocol. The data service is accessed through the service access point protocol.

Description

DISTRIBUTED LOCAL AND WIDE AREA NETWORK INDEPENDENT OF CONNECΗON MEDIA SUPPORTED IN NETWORKED DEVICES, AND MANAGED BY THE NETWORKED DEVICES

This application claims the benefit of U.S. Provisional Application No. 60/133,901, filed May 13, 1999.

The present invention relates to a local and wide area network of networked devices. More particularly, the invention relates to data devices as networked devices that provide data services in a mobile environment.

Conventional design architectures of mobile phones provide the user with a conveniently compact product well suited to voice communication. However, such conventional design architectures exhibit limitations. The design architecture is closed. Upgrades, applications, or accessory products cannot easily be added at a later date after initial purchase of a mobile phone. For new generation products new services will be appearing constantly. Mobile phone manufacturers will not be able to design ahead for such services and the addition of new services will mean a product redesign. As a result the life span of products will reduce considerably. All the phone applications must use the same size- constrained display, and generic keypad. If a general user interface is used the display dictates a larger product, and the assumption is made that all users will be computer literate. This approach is expensive, and is only valid for high tier products, addressing the needs of only a limited percentage of the consumer market. The user interface is integrated into the phone product and provides the means for accessing and driving all of the available data applications. With the foreseen increase in data functionality this will lead to increased complexity of the user interface, making it less user friendly. The pressure on the manufacturer to reduce the product size, and hence display size compounds this. The ergonomics are also ill suited to the forthcoming expansion in data services. This is more easily highlighted with an example. During a mobile phone conversation one party sends a report to the other via email. The two parties are discussing the report and want to view it whilst they are talking. To view or edit the report, each party must remove the handset from his ear, and the conversation is interrupted. If the products have speakerphone functionality the conversation can continue but with reduced privacy. There are many data applications, which have different ergonomic requirements. Compare for example the requirements for a portable video conferencing product to those for a weatherproof sports headset communicator. The latter has no place for a large display screen.

Next to mobile phone systems, there are high-end consumer network systems. These high-end network systems offer distributed computing services with so-called 'plug and play' providing generic hardware compatibility and automatic configuration of software drivers for the required service. When these systems become available the user will be able to connect to the required service simply by 'plugging in'.

The emphasis on data communications in the mobile environment is expected to grow. It is logical that the mobile phone itself can be considered as a device offering a service in a mobile distributed computing network. The user must have easy access to the services provided on this distributed network. If this mobile network can also interact with the fixed proprietary networks currently under development, usage of the mobile phone in the home environment can be promoted. The fixed network systems under development that are relevant for mobile phone considerations are as follows:

HA VI - This system provides consumer electronic products access to the home network. The home network utilizes the IEEE 1394 standard bus, which has a bandwidth of 400Mbps.

JINI - This is a communication layer based on JAVA. JLNI requires a lot of processing power, fast memory, and a high network bandwidth (in the order of 100's Mbps). There are plans to merge this with HA VI to provide a fixed consumer product network. USB - This is a plug and play bus system with a bandwidth of 12Mbps suited to fixed local area networks. Hardware connection to the bus is defined in the standard. These fixed networks are aimed at high bandwidth relatively expensive networks. The mobile phone environment is substantially different as follows:

The maximum available bandwidth will typically be in the order of 2Mbps, and will vary depending on the mobility of the user.

The transfer of network configuration data must be restricted since the user will pay for all data transmitted over the air. Hence there is a network restriction imposed by the mobile communication environment which all fixed networks do not have. The number of devices connected to the mobile network at any one time will be small. The cost and size constraints are such that a JAVA virtual machine may not be available for most devices, particularly the phone itself.

The life of the mobile network is short. Wide area coverage is limited to the call duration. The network is configured to suit the user's requirements each time it is required.

There are currently various schemes under development for providing remote wireless point to point, and point to multi-point connectivity. In particular the Bluetooth, HomeRF and IrDA technologies are of interest for mobile phone products.

It is an object of the invention to provide a novel architecture of a distributed local and wide area mobile network.

It is another object of the invention to provide a mobile network managed by networked devices virtually, not requiring a centralized server or service provider support. It is still another object of the invention to provide mobile devices in a mobile network that are cheap to purchase and operate, and bandwidth limited so that mobile network overhead is not memory or bandwidth intensive.

It is still another objective of the invention to provide functional modularity in a mobile network. It is still another object of the invention to provide a network architecture in which existing data service and new data services can easily be updated or added.

In accordance with the invention, a dynamically configurable network is provided comprising: a first data station comprising a first service application layer protocol providing a first data service, and a first physical layer protocol; a first wireless protocol station comprising a second service application layer protocol, said first wireless protocol station being configured to physically exchange data with said first data station via a first communication link using said first physical layer protocol, and being configured to access said first data service via a peer-to-peer communication using a service access point protocol comprised in said first data station and in said first wireless protocol station, in said first data station said service access point protocol being configured to transfer data between said first service application layer protocol and said first physical layer protocol, and in said first wireless protocol station said service access point protocol being configured to transfer data between said second service application layer protocol and said first physical layer protocol, said first data station and said first wireless protocol station forming a first local area network node in said dynamically configurable network. The invention is based upon the insight that through a service access point protocol comprised in data and protocol stations, in a layer between a service application layer and a physical layer, stations can be added to a node or to nodes, thereby facilitating a variably sized network configured by a user or automatically for the duration of the user requirement. Preferably, the network comprises a second wireless protocol station in a second local area network node, thereby expanding the concept of a dynamically configurable local area network to the concept of a dynamically configurable wide area network comprised of a number of inter-linked local area networks.

Preferably, data transfer between stations is packet-switched. Preferably, controller stations in the network, i.e., stations that are part of a current data service request, operate on the basis of directories that comprise dynamically created direct or indirect network node and station addresses, to support direct and indirect transfers with minimum control and routing data overhead. With indirect transfers, intermediate stations update intermediate destinations of a next station on the basis of directory entries comprising a next stations node and station address.

Preferably, directories within stations are updated through a station scanning process for acquiring node and station addresses of newly acquired stations.

Figure 1 shows a local area network according to the invention.

Figure 2 shows a wide area network according to the invention. Figure 3 shows another representation of a wide area network according to the invention.

Figure 4 illustrates access to network services via a MADI service access point.

Figure 5 shows interaction of stations within a MADI local area network node. Figure 6 shows a protocol station in a node of a MADI- WAN providing interconnectivity to external nodes.

Figure 7 shows positioning of protocol layers in a MADI-WAN. Figure 8 shows data transfer between nodes of a MADI- WAN.

Figure 9 shows a structure of a parent transport packet.

Figure 10 shows a transfer packet from a PDA to a mobile phone, in a first node.

Figure 1 1 shows a transfer packet from the mobile phone in the first node to a mobile phone in a second node.

Figure 12 shows a transfer packet from the mobile phone in the second node to a PDA in the second node.

Figure 13 shows a service station record in a MADI service list.

Figure 14 shows an overall structure of a MADI service list.

Figure 15 shows a structure of a transmit and receive service transfer interface.

Figure 16 shows service data encapsulation.

Figure 17 shows a directory record format in a MADI controller.

Figure 18 shows an overall directory structure.

Figure 19 shows directory contents of directory records in a number of MADI controllers.

Figure 20 shows a MADI-SAP software architecture.

Figure 21 shows MADI transport management.

Figure 22 shows a MADI transfer buffer structure.

Figure 23 shows fixed network mobility, using MADI.

Throughout the figures the same reference numerals are used for the same features.

As will be described in detail hereinafter, broadly the invention provides

Mobile Auxiliary Device Interoperability (MADI) and provides a framework to allow mobile phones and their peripheral devices to interact in a wide area network comprised of numerous interconnected local area networks.

Figure 1 shows a local area network 1 according to the invention, a MADI local area network that is comprised of a Protocol Station 2 (PS) and associated Data Station (DS) devices, a printer 3, a television set 4, a music center 5, a personal computer 6, which are fixed data stations, and a watch 7, a camera 8, a music player 9, a personal digital assistant 10, and a headset 11, which are wireless mobile data stations. The protocol station 2 can provide a two-way over-the-air link to a base station service of a cellular network (not shown in detail here), and in a stand-alone capacity may only offer the user voice-only functionality via a simple numeric keypad. Such a stand-alone capability is well known in the art of cellular telephony. Data services can be, and typically are transparent to the user in the MADI protocol station 2. In this respect, the protocol station 2 is a transparent data pipe providing a gateway to the data service for the DS devices 3 to 11. Typically, all data applications are serviced via the ancillary DS devices 3 to 1 1. The DS devices 3-1 1 have user interfaces well suited to their specific task. The variety of DS devices 3 to 11 provides the user with a choice of user interface. For example, if a data station device is used to perform a speakerphone voice communication the powerful PS transmitter can remain away from the user's ear, in a shoulder bag or briefcase for instance. Some of the data station devices 3 to 1 1 may be designed specifically to utilize specialized Internet data services, e.g. a portable music player that "records" tracks from an Internet service. The MADI architecture is open and facilitates easy addition of new services and data station products without a substantial change to the protocol station 2. The data station devices 3 to 11 are configured to communicate with the protocol station 2 via standardized communication links to form the local area network 1. The physical interfaces within the local area network may be comprised of a variety of different standards such as a Bluetooth RF link to the headset 11 , or an IRDA connection to the printer 3. Since the protocol station 2 in the local area network 1 can communicate with another PS, which in turn is also capable of supporting it's own local area network, the notion can be extended to a wide area network where any data station device can be connected to any other via the mobile service.

Figure 2 shows one representation of such a wide area network according to the invention, a MADI wide area network, and Figure 3 shows another representation of the MADI wide area network.

Shown in the system in Figure 2 are, in a local network 20, local data stations (LDS) 21, 22, and 23, and a local protocol station (LPS) 24, and, in a remote network 25 that is remote to the local network 20, a remote protocol station (RPS) 26, and remote data stations 27, 28, and 29. In the system all devices can access each other and are considered as devices connected by a MADI network that is shown schematically in another representation in Figure 3. For a local data station in the local network 20 to communicate with a remote data station in the remote network 25 the successive paths for communication are as follows: a local LDS communicates with a local LPS, the local LPS communicates with a remote RPS, and the remote RPS communicates with a remote RDS. It can be seen therefore that the message routing requirements of the MADI network 30 are specialized to the mobile environment. By their very nature mobile products move around. Access to peripheral devices is transient. This means that the MADI network 30 must be dynamically configured each time it is required. It is also quite likely that an LDS user might request access to another LDS device without a PS in the local area network. For example the user of a local personal digital assistant might want to print an agenda on a local printer. There is certainly no need for a PS in this instance. It is important that the MADI system is kept as simple and flexible as possible.

The network needs to be utilized in an efficient manner and must provide a simple means of access to the devices required. To this end the following facilities are provided: coordination of the control of several devices simultaneously, timely and efficient transfer of both control information (one device sending a command to others), and data content (one device sending a data stream to others), and simple User configuration of a just- in-time, just-the-right-size network tailored to the specific needs of the user. Since the network is designed for portable products, power, memory overhead, and the cost of remote network transmissions are minimized. In addition thereto, the network is self-managed, multiple device access protocols are supported, new device access protocols can easily be added, and an interface to other fixed consumer networks is provided.

To provide these services a network management system is required, the MADI system.

The MADI system according to the invention, a network management system, can be viewed as a distributed computing platform, and the primary goal of the MADI system is to assure that products can inter-operate to perform application tasks. To facilitate a generic interface to the MADI network the architecture defines a set of Application Programming Interfaces (API's). As will be described in further detail hereinafter, the MADI architecture is an open, lightweight, platform-independent and architecturally neutral specification, provides the infrastructure to control the timely routing and processing of data, supports legacy devices that do not support the MADI architecture, support Future devices through software-based mechanisms, allows devices to present multiple user interfaces, adapting to both the users' needs and the manufacturers need for brand differentiation, and facilitates the transparent transfer of peer to peer communication data to support higher layer network systems and communication protocols such as those used in fixed network systems e.g JINI. The services provided in the MADI system are distributed over the network within the connected devices. Services run under an execution environment in a device and are accessible through a well-defined interface. In this respect it is noted that different devices may use different execution environments. The services sit on top of a peer-to-peer communication layer provided by the MADI system. The MADI layer according to the invention provides a mechanism for data exchange between these service entities and provides the facility for specifying the organization of the data exchange. The specifics of the service interface are of no concern to MADI. Services can be provided by device manufacturers, or can be added by third party vendor services (such as new vendor applications added to manufacturers' devices). Services are requested and provided via a MADI message-passing model, which provides a completely generic software model that is sufficiently flexible to allow multiple implementations with a variety of software systems and languages.

Figure 4 illustrates access to network services via a MADI service access point 40. The SAP 40 exists in all MADI compliant stations, in data station devices and protocol stations, and provides a peer to peer communication layer between the service entities. In Figure 4 a service layer 41 is shown.

Figure 5 shows interaction of stations within a MADI local area network node (Node 0) 50. The node 50 comprises data stations (DS) 51 and 52, and a protocol station (PS) 53. The stations 51 to 53 all have a MADI layer according to the invention.

Figure 6 shows the protocol station 53 in the node 50 of a MADI- WAN (Wide Area Network) providing interconnectivity to external nodes 60 and 70 (Node 1 and Node n). The external node 60 comprises data stations 61 and 62, and a protocol station 63. The external node 70 comprises data stations 71 and 72, and a protocol station 73. The MADI- WAN (Wide Area Network) is comprised of numerous local area network nodes interconnected via protocol stations. A MADI service access point of a type shown in Figure 4, facilitates distribution of the services provided by each station to all others in the MADI- WAN. The protocol station 53 provides interconnectivity to the external nodes 60 and 70. Figure 6 shows all possible interconnect paths. Stations within a MADI network are either Controller or Controlled stations. Controller stations request a service or services from

Controlled stations and possesses knowledge, or a view of, the network. Controller stations know all the services available, and the access mechanisms to obtain them. Controlled stations act as dumb stations and respond only to the instructions given. They do not have knowledge of the network. This reduces the need for unnecessary network configuration transmissions and limits the transfers of directory information. Other Controller stations can also control Controller stations since they too may offer services to the MADI network.

Figure 7 shows positioning of protocol layers in a MADI- WAN of the type shown in Figure 6. Shown are protocol layer stacks for data stations and protocol stations. A data or protocol station has the following protocol layers:

Low-level physical media layers 80 to 87 - providing the physical interface to other stations. There will be a selection of different media interfaces within the MADI network 30. One station may have access to numerous media options such as UMTS, Bluetooth, IrDA, or others, indicated by Ml, M2, M3, or M4. Other media options are HomeRF, or RS232, for instance.

MADI SAP layers 90 to 97 - sit above the lower-level physical media layers 80 to 87, and provide the network and data link layers for MADI communication. The MADI SAP layers 90 to 97 are largely independent of the low-level physical media layers 80 to 87. Some stations in the network might also support higher layer networks such as JINI. In these stations, such as in data stations 98 and 99, the MADI SAP layers 91 and 95 sit directly underneath the higher network layer, in the example given respective JLNI layers 100 and 101. In this instance the MADI layer extends the higher layer network to the higher layer compliant stations in the MADI network.

Service layers 110 to 117 - sit above the MADI SAP layers 90, 92 to 94, 96 and 97, or as the case may be, above the JLNI layers 100 and 101. In Figure 7, the data station 98 sits in a first local area network 118, and the data station 99 sits in a second local area network 119, the networks 118 and 119 being remotely connected to each other.

Protocol stations comprise all media options of data station devices they support, in the example given Ml to M4. Data stations typically have less media options or even only one media option.

To facilitate concurrent control and data transfer between network entities and to provide maximum flexibility for data transfer all network transfers are in the form of the Transport Packet shown in table-I below.

Table-I As shown in table-I, the Transport Packet comprises several Packet Segments:

A Destination segment, which defines the packet destination. The destination segment comprises a Destination Node Identifier DNODE, and a Destination Station Identifier DSTATION.

A Data segment containing the transfer information. The data segment comprises a Command Identifier COMMAND, an Information Field Length ILEN, and Information INFO. A Source segment, which defines the originator of the packet transfer. This information is necessary to facilitate an acknowledgement. The Source segment comprises a Source Node Identifier SNODE, and a Source Station Identifier SSTATION

A Validation segment to detect any packet corruption due to processing errors. The Low-level physical media layers 80 to 87 below the MADI layers 90 to 97 provide error detection and correction for communication errors. The Validation Segment comprises a Checksum CHKSM.

Figure 8 shows packet data transfer between nodes of the MADI-WAN 30. Shown are nodes 130 and 140 (Node 1 and Node 2), and transfer paths or interfaces A to G for internal-node or node-to-node transfers. The node 130 comprises data stations 131 and 132, and a protocol station 133. The node 140 comprises data stations 141 and 142, and a protocol station 143. In the example given, the data station 131 is a PDA, the protocol station 133 is a mobile phone, the protocol station 143 is a mobile phone, and the data station 142 is a PDA.

Direct transfers can be performed in which data are transferred directly to a destination station, such as a transfer over interface A in Figure 8. The destination segment, with the fields DNODE and DSTATION, in the transport packet defines the target recipient of the message, and the source segment, with the fields SNODE and SSTATION, defines the sender. The sender of a service request preferably is identified in each transfer packet. Herewith, acknowledgements can be returned by the controlled station, without the need for knowledge of the network. Packets in the network can be readily interspersed, since all received packets are identified.

For indirect transfers via other stations, such as in the case of DS-DS out-of- node transfers, intermediate stations relaying the packet do not need to store any message history for the return acknowledgment transfer. Indirect transfers are transfers which are sent via an intermediate station to the destination station. Indirect transfers are comprised of a number of intermediate transfers. For example in Figure 8 a transfer from node 130 data station 131 to node 140 data station 142. remote transfer between two Personal Digital Assistants (PDAs) is indirect, and requires transfers over interfaces B, D and G. Alternatively, this indirect transfer could also occur with transfers over interfaces A, C, D, E, and F.

For all intermediate transfers the transport packet is encapsulated in the INFO field of a parent transport packet. The parent packet provides all the information necessary to perform the immediate transfer. The encapsulated packet contains all the information required to determine the transfer path en-route to the final destination.

Figure 9 shows a structure of a parent transport packet 150. The packet 150 comprises similar fields as a packet described in relation to table-I, but with final destination information in a parent information field so that intermediate transfers can be performed between stations, with a minimum of overhead information. With reference to Figure 8, an indirect transfer is performed from the node 130 station 131 to the node 140 station 142.

Intermediate transfers pass over interfaces B, D and G and the command and INFO to send is X and Y accordingly. The parent transport packet 150 is comprised of a parent destination segment, a parent data segment, a parent source segment, and a parent validation segment. The parent destination segment comprises a parent destination node identifier (PDNODE) 152 and a parent destination station identifier 153 (PDSTATION) defining an intermediate destination for packet delivery. The parent data segment comprises a parent command field 154 (PCOMMAND) that defines the action at the intermediate station, and denotes how to interpret a parent information field length 155 (PILEN) and a parent information field 151 (PINFO) comprised in the parent transport packet 150. The parent validation segment comprises a parent checksum 156 (PCHKSM). The parent source segment comprises a parent source node identifier 157 (PSNODE) and a parent source station identifier 158 (PSSTATION). In a chain of intermediate packet transfers from an initiating parent source station to a final destination station, intermediate stations become parents and update the encapsulating fields accordingly so that the packet transfer is done with the minimum overhead. The parent information field 151 (PINFO) comprises a final destination node address 160 (DNODE), a final destination station address 161 (DSTATION), a command field 162 (COMMAND) defining the action at the final destination station, and denoting how to interpret a following information field, an information length field 163 (ILEN), a final destination data field 164 (INFO), an originating source node address field 165 (SNODE) and a source station address 166 (SSTATION) used en-route in the return acknowledgement for transfer path selection.

For direct transfers, oi indirect transfers within the node, an acknowledgment transfer is returned from each receiving station. If an indirect transfer is performed across a node boundary then the acknowledgment process differs. Within the remote node all acknowledgment responses are accumulated in the remote protocol station 143 maintaining the inter-node link. When this activity is completed, by receipt of a final ACK or an error ACK, the remote protocol station 143 sends an acknowledgment report to the local protocol station 133 which then relays it to the initiating data station 131. If a final acknowledgement is not received, knowledge has been accumulated to pinpoint the source of the problem to the user.

Figure 10 shows a transfer packet 170 from the PDA 131 to the mobile phone 133, in the node 130. For all packets throughout the chain of packets from the PDA 131 to the PDA 142, the contents of the parent information field 151 is the same, namely the final destination node/station address 140/142, a command X at the final destination address 140/142, a length information field 163, a destination information field 164 (Y), and originating node/station address 130/131. The length information field 163 defines the length of the destination information field 164. As parent packet information encapsulating the parent information field 151 , the packet 170 contains the intermediate station destination node/address of the protocol station 130/133, the mobile phone 133 in the node 130, and source node/station address 130/131 of the originating PDA 131 in the node 130, and further the parent command "NETWORK_RQST_INDIRECT_SEND" to instruct the mobile phone 133 that the information is not intended for it but that the packet should be sent to another station. Figure 11 shows a transfer packet 171 from the mobile phone 133 in the node to the mobile phone 143 in the second node 140. As parent packet information encapsulating the same parent information field 151, the packet 171 contains the intermediate station destination node/address of the protocol station 140/143, the mobile phone 143 in the node 140, and source node/station address 130/133 of the intermediate mobile phone 133 in the node 130, and further the parent command "NETWORK_RQST_INDIRECT_SEND" to instruct the mobile phone 143 that the information is not intended for it but that the packet should be sent to another station.

Figure 12 shows a transfer packet 172 from the mobile phone 143 in the 140 node to the PDA 142 in the node 140. As parent packet information encapsulating the same parent information field 151. the packet 172 contains the final station destination node/address of the data station 140/142, the PDA 142 in the node 140. and source node/station address 140/143 of the intermediate mobile phone 143 in the node 140. and further the parent command "NETWORK_RQST_LNDIRECT_DELIVERY" to instruct the PDA 142 that the information is intended for it.

An Application Programming Interface (API) is provided to present the MADI SAP to the higher layers in a simple, convenient manner. The API provides access to all MADI functionality, and to the distributed set of services in the MADI network. The API consists of a single MADI Service List, and numerous MADI Service Transfer Interface Instances.

Figure 13 shows a single service station record 180 in a MADI service list. Figure 14 shows an overall structure 190 of a MADI service list. The MADI Service List provides a "view" to the higher layers of all the services available in the MADI network 30, and lists key information about those services. In the example given, the user selects the service stations to be accessed or controlled, (although this need not be the case) so the user is provided with a short ASCII text description for each of the service stations available. This is presented in a Service Station Tag field 181 (STNTAG). The record 180 further comprises a Service Station Node field 182 (NODEID) and a Service Station Identifier Field 183 (STNID) field that provide the higher layer with the service station address of the service station offering the service within the network 30. A Service Station Attribute field 184(STNATRB) is provided to indicate to the higher layer specific capability information about the service station. For example, if the higher layer needs to connect to JINI enabled devices the STNATRB fields can be scanned to determine which stations to access if any. This reduces the number of transfers since individual stations in the network do not need to be polled with a compatibility request. The service station receive capability is presented in the Service Station Receive Capability field 185 (STNSLZE), to support the varying limitations on memory in MADI compliant stations. The field 185 defines the maximum size of the information field that can be received and stored in the service station. The controller station performing the transfer can verify the transfer packet size prior to sending it. This overcomes the issue of transfers being sent which are too large for the receiving station, which would otherwise result in return error acknowledgments. The STNSLZE field 185 thus greatly reduces the number of transfers. In Figure 14, service station records 191 to 194 are shown (Record 1, Record 2, Record 3. and Record n). A MADI Service Transfer Interface (MTSI) provides a gateway to the MADI services. It is through this interface alone that access is gained to the MADI layer. To understand the MSTI it is necessary to briefly discuss the underlying principles. Firstly, it is important to ensure that the processing power and memory requirements for the MADI layer are minimized so that all stations can be compliant. However, if the MADI layers 90 to 97 cannot adequately process transfers within the network there will be a large amount of retransmission and inefficiency built into the network system. Since the transfer mechanism is packet-based the following concepts for communication are established. Within a MADI compliant station: Transmission can be restricted to occur sequentially, i.e. one transmission after another. Reception can be restricted to occur sequentially, i.e. one reception after another. Transmission and Reception shall be concurrent, i.e. reception can occur whilst a transmission is in progress. This means that all MADI compliant stations are capable of full duplex communication within the network at all times. The MSTI shall therefore be comprised of one Transmit Transfer Interface (TXSTI), and one Receive Transfer Interface (RXSTI) as a minimum requirement. There will however, be a large variation in the memory limitations of MADI compliant stations. Some of the more powerful stations with a fuller complement of memory (such as the protocol stations) may find it useful to transmit multiple transfers concurrently, and also receive multiple transfers concurrently. The MADI layer shall facilitate this by supporting multiple TXSTI and RXSTI instances. Figure 15 shows a structure of a transmit and receive transfer interface 200

(TXSTI/RXSTI). The structures of the TXSTI and the RXSTI are identical, although completely separate, and are as shown in Figure 15. A higher service layer as shown in Figure 7 requests a MADI service via the TXSTI. The higher layer loads the TXSTI interface with the following: A destination address of the service station providing the service. The destination address comprises a destination node address 201 and a destination station address 202. The higher layer obtains this from the MSL as shown in Figures 13 and 14; a MADI command 203, as will be described in more detail, the command 203 defining the action at the final destination and denoting how to interpret an information field; a length of data field 204 to indicate a length of a INFO field; transfer data if necessary in the INFO field; a source address of the station initiating the transfer, the source address comprising a source node address 206 and a source station address 207. For service requests in other stations the TXSTI request is transferred through the MADI network 30 and delivered to a higher service layer in the receiving station via the MADI layer RXSTI.

In table-II below, the commands available in the MADI command set are shown.

Decimal Command Type Description Value

0 - 99 Service Set Service commands delivered to the service layer above the MADI layer. Examples of such commands are as follows: SERVICE_RQST_CTRL_MGR - Requests an encapsulated UI model for download to the controller, so that the user can control the service via a graphical UI.

SERVICE JIQST ^>RMPT_LST - Requests a controller UI prompts list for download to the controller, so that the user can control the service via text prompts.

SERVICE IQST_SHRT ^>RMPT LST - Requests a reduced length controller UI prompts list for download to the controller, so that the user can control the next service action via a text prompt. SERVICE_RQST_SECURED_CTRL - Requests control of the receiving station for services protected with a password SERVICE_ACK_FINAL - Service command received and accepted

SERVICE_ACK_ERROR_l - Service command received not valid

100 Extended Service specific commands are delivered to the Service Set service layer and are defined specifically for the particular service. The service specific command is Table-I

The command types are defined and numerous examples are given. The stations themselves are considered as the service within the MADI networking strategy. Service commands are passed between the service layers in the network service stations via the peer-to-peer MADI layers as shown in Figure 7. To deliver a service command to a service layer in another station a parent transport packet is used as shown in Figure 9. The COMMAND field is loaded with a service delivery command (see the above table-II) which indicates the requirement for a delivery to the service layer and denotes the format of the ensuing INFO section. The service command (or extended service command) for delivery to the service layer is embedded in the INFO section. With reference to the intermediate transfer as shown in Figure 10, a service delivery could be as follows: COMMAND = X = 120 and INFO = Y.

Figure 16 shows service data encapsulation, with the INFO - Y, a field 210, service priority, a field 211, service identifier, a field 212, service command, a field 213, service information field length, and a field 214, service information. The extended service set of service specific commands facilitates the use of commands defined specifically for a particular service. To use the extended service set the service command in Figure 16 is set to 100. The service specific command is then presented in the first location of the Service INFO field.

A directory of the MADI network must be maintained so that the service stations can be selected to provide their services. The temptation to distribute the current directory information amongst the stations constituting the network must be resisted since transmission bandwidth, power consumption, and the cost of cellular over-the-air transmissions are of primary importance.

In the MADI system a network comprises an initiating controller station and one or more controlled stations. If at any time a controlled station acquires the services of another station or relays information to another station it becomes a controller station. A controller station must possess the current directory knowledge in order to issue requests for service within the network. It must be able to "see the network", whereas a controlled station "blindly" follows its instructions and responds accordingly. Each controller is therefore provided with a directory.

Figure 17 shows a directory record format 220 in a MADI controller. The record 220 comprises a Service Station Node Identifier 221 (NODEID), a Service Station Identifier 222 (STNID). the identifiers 221 and 222 defining the address of the service station offering the service to the network 30. The record 220 comprises a Service Station Receive Capability field 223 (STNSLZE) that defines the maximum size of the information field that can be received and stored in the service station. The record 220 comprises a Service Station Attribute field 224 (STNATRB) that defines the service station capability to higher layer networks such as JLNI networks. The record 220 comprises a Service Station Tag Field 225, an ASCII Text description of the service station for user selection purposes. The record 220 comprises a Service Station Access Identifier field 226 (STNACC) that defines the physical media for direct access, e.g., 1=UMTS, 2=Bluetooth, and 3=TrDA, 255=indirect access required via an intermediate station defined in fields 227 (ANODEID) and 228 (ASTNID). In case of indirect access, the field 227 defines an Indirect Access Service Station Node, and the field 228 defines an Indirect Access Service Station Identifier, for indirect access to the service station offering the service.

Figure 18 shows an overall directory structure. Shown are records 230, 231, 232, and 233.

With reference to the example given in Figure 8, the media access fields illustrated in Figure 17 are clarified with directory contents of the data station 131 and the protocol station 133 in the node 130, and of the protocol station 143 and the data station 142 in the node 140, the stations 131, 133, 143, and 142 being MADI controllers.

Figure 19 shows directory contents of directory records in the MADI controllers. A shown in Figure 19, the controllers in the example have the access fields 221 , 222, and 226 to 227 (NODEID, STNID, STNACC, ANODEID, and ASTNID) in their directories.

It may be the case that a local node grows due to the addition of other local service stations. To provide the increased level of services to other stations in the network it must be possible to exchange directory listing information between controllers. The MADI system shall provide a full range of network commands supporting a whole host of directory exchange commands.

For Directory Updates, the following rules apply:

The controller station relinquishing the service supports it by providing the link access to it. This means that the following fields are passed as follows: STNACC = 255;

ANODEID = Node identifier of the controller station passing the entry; ASTNID = Station identifier of the controller station passing the entry;

For indirect directory transfers, the passed directory information is added to all of the intermediate stations' directories, with the ANODEID and ASTNID being modified as stated for each intermediate transfer. Received directory records will be disregarded if the NODEID and the STNID already exist in the director)'. If a station in the directory has a STNACC field = 255. and a node scan acquires the station directly then the STNACC, ANODEID, and ASTNID fields are updated with the direct access information. Controllers do not log directory records which contain their own NODEID and a STNID. This methodology enables controller stations to exchange directory structures simply and without a lot of processing power. It minimizes the size of the structures since indirect access paths are delimited to the first station en-route. As a general point, the use of separate Node and Station identifiers does add some overhead to the MADI transfer packet size and the directory memory requirements. However, this methodology provides for flexibility in the system. If the node and station identifiers were replaced with a single station identifier the values would have to be assigned globally throughout the network. Every directory would need to be updated automatically whenever a station was added to a local node. This would impact station power consumption and overall transmission bandwidth. With the chosen methodology, MADI commands can be provided to enable the user to add certain nodes of another WAN as required, or send a certain station directory entry to another user so that they can connect to just one station of the remote node. It empowers the user within their network, and offers savings in bandwidth and power.

Some functionality aspects associated with the passing of intermediate transfers will now be described. With reference to the example system shown in Figure 8, and the transfer packets defined in Figures 10, 1 1 and 12, the actions that need to take place within the MADI layer for the example received NETWORK_RQST_LNDIRECT_SEND command.

The receiving station compares the DNODE and DSTATION with the directory listing, and from it configures new values for PDNODE, PDSTATION, and

PCOMMAND, reconfigures the PSNODE and the PSSTATION to the stations own values, recalculates the PCHKSM, and sends the reformatted message on to the new destination.

An acknowledgment is returned. To configure the return acknowledgment the station performs the following actions: configures the PDNODE, and PDSTATION values from the received

PSNODE and PSSTATION values; configures the PCOMMAND to be the same as the received PCOMMAND either a NETWORK_RQST_INDIRECT_SEND, or a NETWORK_RQST_INDIRECT_DELIVERY; configures the PSNODE. PSSTATION, SNODE. and SSTATION values to the stations own address values; configures the DNODE. and DSTATION values from the received SNODE and SSTATION values; configures the COMMAND depending on the received PCOMMAND; configures ILEN = 1 ; configure the INFO field to contain the acknowledgment information e.g. VALID_RECEPTION or an error code; recalculates the PCHKSM; and sends the acknowledgment to its destination. A

NETWORK_RQST_INDIRECT_SEND returns a NETWORK_ACK_INTERMEDIATE. A NETWORK_RQST_LNDIRECT_DELIVERY returns a NETWORK_ACK_FLNAL.

Shown are directory contents 240 of the data station 131, the controller Cl, directory contents 241 of the protocol station 133, the controller C2, directory contents 242 of the protocol station 143, the controller C3, and directory contents 243 of the data station 142, the controller C4.

With reference to Figure 8, it can be seen that the directory contents 240 of the controller Cl has records for direct transfer via transfer paths A and B, to the stations 132 and 133, and has records for indirect transfer, the protocol station 133 in the node 130 being the first intermediate station for indirect access to the service stations 141, 142, or 143 offering the service in the network 30, and the controller Cl requesting the service.

Similarly, the controller 133 has three direct transfer paths, B, C, and D, and two indirect transfer paths to the service stations 141 and 142 for which the controller 143 is the first intermediate station. Similarly, the controller 143 has three direct transfer paths, E, G, and D, and two indirect transfer paths to the service stations 131 and 132 for which the controller 133 is the first intermediate station.

Similarly, the controller 142 has two direct transfer paths, F and G, and three indirect transfer paths to the service stations 131, 132 and 133 for which the controller 143 is the first intermediate station.

Figure 20 shows a MADI-SAP software architecture with a MADI layer 250. The MADI layer consists of a processing sub-layer 251 and a driver sub-layer 252. The processing sub-layer 251 performs MADI network processing control. Above a validation layer 253 that validates incoming checksums, calculates and appends outgoing checksums, validates incoming destination addresses and data lengths, and reports status, the processing layer 251 comprises the following managers: a Message Manager 254: handles all internal message passing between the software elements, and layers; a Directory Manager 255: performs all directory operations such as compilation, modification, clear-down, initialization, information request servicing and service list provisioning for the MSL; a Transport Manager 256: manages the shared transport memory (provides and controls access and status; a Transport Configuration Manager 257: configures the transfer data; a Command Interpreter 258: interprets received commands and performs the actions required, with the exception of the network configuration actions; a Network Manager 259: interprets received network configuration commands and perform the actions required such as the addition/removal of stations to/from the network; and a Media Access Manager 260: Selects the Media Driver for transfer operations.

The driver layer 252 comprises Media Drivers 261, one for each of the media interfaces supported. Shown are a Bluetooth media interface 262, an IrDA media interface 263, a UMTS media interface 264, and another media interface 265. The Media Drivers 261 configure MADI output transfer data for the appropriate media interface layer. The Media

Drivers also configure the received data from a media interface for the MADI layer, and report media status. Media Drivers perform all the necessary signaling and data management requirements necessary to support the exchange of information between the MADI processing sub-layer 251 and the Media layer. A Media Driver Interface 266 provides a consistent exchange mechanism between the processing sub-layer 251 and the driver layer

252. This facilitates the easy addition of new media interfaces when they become available.

The addition of a new Media Driver to the driver sub-layer 261 is all that is required to support a new media interface within the MADI layer. The Transport Configuration Manager 257 configures an added new Media Driver. The Media Access Manager 260 selects a Media

Driver. Further shown in Figure 20 are Service Applications 267, 268 and 269 above the

MADI layer 250, a MADI Service Application Programming Interface 270, and a Media

Layer Application Programming Interface 271 Figure 21 shows modeling of transport data through the MADI layer 250. The mechanism for transferring the communicated data through the MADI layer 250 must be made as efficient as possible, in view of the memory limitations imposed by the variety of mobile products that will need to be compliant, and the timing constraints of the system. To this end it is envisaged that a system of shared memory will be utilized. A single buffer is used to propagate the MADI transfer data through the MADI layer 250. There are. as a minimum, 2 buffers in the MADI layer 250, although there may be more. This ensures that the requirement for full duplex communication is met for all compliant stations. In this respect, a variable buffer size provides greater flexibility within the system. For example, a particular station might want to be able to deal with a high rate of short messages. If variable buffer sizes are supported the station can chose to only accept short messages, and can provide itself with a larger number of MADI transfer buffers without using any more memory. For this reason the MADI system supports variable size transfer buffers. This is facilitated via the STNSLZE field in the MSL (as shown in Figure 13), and the directory records (as shown in Figure 17). Service applications check their transfer lengths against the MSL before requesting the transfer. If a station receives an oversized transfer packet, the station shall reject it and return an error acknowledgment. In Figure 21, MADI transfer buffers 280 are shown that buffer Service transfer data 281 exchanged via the MADI service API 270, and Media transfer data 282 exchanged via the Media Driver Interface 266. Further shown are a MADI_Send_Indication 283 that indicates a send requirement and identifies an associated buffer, a MADI_Send_Report 284 that reports the send status (valid or in error) and identifies an associated buffer, a MADI_Delivery_Indication 285 that indicates a MADI reception event, delivers reception status (valid or in error), and identifies an associated buffer, a Media_Send_Indication 286 that indicates a send requirement and identifies an associated buffer and media driver, a Media_Send_Report 287 that reports a sent status (valid or in error), and identifies an associated buffer, and media driver, a Media_Delivery_Indication 288 that indicates a Media reception event, delivers reception status (valid or in error), and identifies an associated buffer and media driver, and a MADI_Memory_Status 289 that denotes buffer availability and allows for its acquisition. Further shown is a Service Layer 290. Exchange of information is full duplex, with a transmit and a receive operation.

With reference to Figures 20 and 21, a transmit operation is performed as follows: A service application selects an available buffer from the MADI Transfer buffers 280 using the MADI_Memory_Status 289, which indicates which buffers are available. Service data is loaded into the available buffer after the service has acquired the buffer resource by updating the MADI_Memory_Status 289. The service application then sends the MADI_Send_Indication 283. which indicates to the MADI SAP, which buffer to send. On receiving the MADI_Send_Indication 283, the MADI processing layer 251 parses the associated MADI Transport buffer and creates a parent transport packet if required. Once the transport packet is configured correctly, the processing layer 251 sends the Media_Send_Indication 286 to the driver layer 252. This indicates which driver to use for the transfer and the buffer containing the transfer packet. When a specific Media Driver has completed the transfer it reports the send status to the processing layer 251 via the Media_Send_Report 287, which identifies the associated buffer, the media driver used and the error status (valid or in error). When the processing layer 251 receives the Media_Send_Report 287, it then configures and returns the MADI_Send_Report 284 to the service layer, which identifies the associated buffer, and the error status (valid or in error). With reference to Figures 20 and 21 , a receive operation is performed as follows:

A particular Media Driver acquires an available buffer using the MADI_Memory_Status 289, which indicates which buffers are available. Once the Media driver has acquired a buffer resource by updating the MADI_Memory_Status 289, an incoming transport packet is loaded into the available buffer. When the buffer load is complete the Media driver sends the Media_Delivery_Indication 288 to the processing layer 251. This indicates a Media reception event, delivers the reception status (valid or in error), and identifies the associated buffer and media driver. Upon receiving the Media_Delivery_Indication 288, the processing layer 251 parses the received data and performs the following actions: the received data is validated, and the appropriate acknowledgment is sent. A separate small acknowledgment buffer may be required to send the acknowledgement. The responsibility for acknowledgment of the service commands rests with service layer 290. Service commands are provided to enable handshakes to be performed if required. The MADI layer 250 however always acknowledges reception of a transfer. For a valid reception the necessary actions are performed. If the received COMMAND is a service delivery command the processing layer 251 sends the MADI_Delivery_Indication 285 to the service layer 290. This indicates a MADI reception event, delivers the reception status (valid or in error), and identifies the associated buffer. Access to the MADI layer 250 is provided to the Service layer 290 via the MADI Service API (as shown in Figure 21). This is comprised of the MSL. the MSTI. and the signaling as defined earlier. The MSTI is comprised of the TXSTI/RXSTI 200 as illustrated in Fig. 15. These elements of the API are contained within the MADI transfer buffers 280.

Figure 22 shows the MADI transfer buffer structure, with buffer contents for transmit TXSTI or receive RXSTI. The buffer contents match the fields of the transfer packet shown in Figure 12, and comprise a parent destination node address 300 (PDNODE), a parent destination station address 301 (PDSTATION), a parent command 302 (PCOMMAND), a parent information length buffer field 303 (PILEN), an encapsulated parent information buffer field 304 (PINFO), a parent source node address 305 (PSNODE), a parent source station address 306 (PSSTATION), and a parent checksum 307 (PCHKSM). The encapsulated parent information buffer field 304 comprises a final destination node address 310 (DNODE), a final destination station address 311 (DSTATION), a command field 312 (COMMAND), a length field 313 (ILEN), a final destination information field 314 (INFO), an originating source node address field 315 (SNODE), and an originating source station address field 316 (SSTATION).

Support for prioritization of service processing is provided in the MADI system. Some service delivery commands define an INFO format containing a Service Priority field (as shown in Figure 16). All such commands shall be higher priority than all other service commands. This enables the service layer 290 to check the priority of pending MADI deliveries and process them accordingly.

In addition to the described packet-switched service, a circuit-switched service can also be emulated in MADI for a particular service. This would be an independent priority assignment in the service layer 290 triggered by the reception of a

SERVICE_RQST_CIRCUIT_S WITCHED service command. If the service layer 290 has not already assigned the circuit-switched attribute to another service then a service station requesting the circuit- switched service can be assigned highest priority at the service level. Services can provide their own security mechanisms encapsulated in the service INFO field transferred over the MADI system. This will provide a layer of security within the specific service. Some service delivery commands shall define an INFO format containing a password field. This shall provide an additional layer of security on top of the service layer protection. Network commands shall also be provided to configure access permission for a controlled station. The scenario could be as follows: A controller station requests access to a controlled station, which acknowledges with a password request. The controller sends the password to gain access.

In the following some of the main network configuration activities are described. To create a Local Node, the following actions are performed:

A NETWORK_RQST_LOCAL_NODE_SCAN, i.e., a network request local node scan command, is requested in the TXSTI. The MADI layer 250 processes the request and configures a NETWORK_RQST_STATION__SCAN, i.e., a network request station scan command, which it issues via tha Media_Send_Indication 286. The Media Driver in the Driver Layer 252 sends the transfer to an associated Media Interface which performs the transmission. An available station responds with a NETWORK_ACK_STATION_SCAN, i.e., a network acknowledge station scan command, containing its NODEID and STNID (both equal to 0 if not already assigned), STNSLZE, STNATRB, STNTAG and STNACC (as shown in Figure 17). After receiving a NETWORK_ACK_STATION_SCAN the processing layer 251 responds with a NETWORK_RQST_STATION_CONFIG, i.e., a network request station configuration command, containing the NODEID and the STNID which are assigned to the newly acquired station (if values are not already assigned). The processing layer 251 adds the station's information to its directory. The NETWORK_RQST_STATION_SCAN transmission is then repeated until there are no more NETWORK_ACK_STATION_SCAN returns. The processing layer 251 then selects the next Media Driver available and repeats the first five steps of the above six steps. All above six steps are repeated until all the Media Drivers have been exercised. The processing layer 251 then returns a NETWORK_ACK_LOCAL_NODE_SCAN, i.e., a network acknowledge local node scan command, to the RXSTI along with an updated MADI Service List. A local node is thus configured. The above actions exercise all the Media layers present in the local node. Partial local node scans may also be supported to allow only the required media to be scanned.

To create a Remote Node, the following actions are performed: A link between a local protocol station and a remote protocol station must be established by issuing a NETWORK_RQST_CALL_SETUP command, i.e., a network request call setup command, to the TXSTI. This instructs the local PS to call the number provided in the INFO field. In response to a NETWORK_RQST_CALL_SETUP the remote PS returns a NETWORK_ACK_CALL_SETUP, i.e., a network acknowledgement call setup command, containing its NODEID and STNID (both equal to 0 if not already assigned), STNSLZE, STNATRB, STNTAG and STNACC (as shown in Figure 17). After receiving the NETWORK_ACK_CALL_SETUP the processing layer responds with a NETWORK_RQST_STATION_CONFIG. i.e., a network request station configuration command, containing the NODEID and the STNID which are assigned to the newly acquired PS (if values are not already assigned). The processing layer 251 adds the station's information to its directory. If the link between the local PS and the remote PS is already established, the above three steps can be bypassed.

Once the local PS to remote PS link is established, a NETWORK_RQST_REMOTE_NODE_SCAN command, i.e., a network request remote node scan command, can be requested in the TXSTI. This command is transferred to the remote PS. Upon receiving this command the remote PS itself becomes a controller station, and performs a local node scan as defined in the first seven steps of creating a local node. In this manner the remote controller builds its own directory for its local node. When the operation is complete, and the node is built, the remote controller returns a NETWORK_ACK_REMOTE_NODE_SCAN, i.e., a network acknowledge remote node scan command, containing a copy of its local directory information to the initiating station. The processing layer 251 in the initiating station then updates its directory and returns the received NETWORK_ACK_REMOTE_NODE_SCAN to the RXSTI along with the updated MSL. The remote node is thus configured and acquired by the initiating station. The above actions exercise all the Media layers present in the remote node. Partial remote node scans may also be supported to allow only the required media to be scanned. This MADI methodology reduces the transfers over the remote link and thus saves transmission bandwidth and processing power in the system.

Controllers can add new stations to their local node as described with the creation of a local node. This process updates the directory in the local controller only. An option is included to allow notification of directory updates to all connected controllers after a directory update has taken place. To this end, a field is provided in the INFO field of the NETWORK_RQST_LOCAL_NODE_SCAN, and

NETWORK_RQST_REMOTE_NODE_SCAN packets to indicate whether this is required. If a station receives an update indication after a directory has changed then the new directory changes must be requested.

Figure 23 shows a possible scenario, fixed network mobility, using MADI. Shown is a mobile MADI PDA 330, that is a data station that can communicate with a mobile JINI network 331 and a MADI mobile phone 332, that is a protocol station. Inside a home 333, or the like, a MADI fixed or mobile phone 334, that is a further protocol station, is provided that can communicate with the MADI mobile phone 332. Inside the home 333. the phone 334 can communicate with a MADI data station 335. such as a personal computer or television set, that can also communicate with an in-home JLNI network 336.

The advantages of the MADI system are herewith summarized as follows: The concept is simple. A MADI compliant PS can access a limitless array of peripheral DS devices. The complexity of user applications is confined to the DS devices, and not the PS. The PS can therefore be very simple offering voice services to the user via a keypad UI. The PS need not have any kind of display element and can therefore be considered language independent. This means that the same PS product can address markets in many differing countries. Since there is no requirement for a display in the PS, its size is limited only by the battery module, so it can be smaller, and less obtrusive. The PS is compatible to a limitless array of DS devices. The PS is an open architecture and provisions for future new data services, service enhancements, and the addition of new DS products. With a modular design concept the primary protocol unit containing all the elements for the baseband service could be user replaceable. The MADI concept positions the PS as a modular element of a product family, and facilitates easy connectivity to a distributed computing network.

The MADI system provides the facility for self-contained local-area and wide- area networking for any mobile or fixed device. The MADI network is configured simply and efficiently by the user, or automatically by service applications when required. The MADI system is specifically designed for the mobile environment to limit the transmission bandwidth, the processing power and the memory requirements. Network management overheads are generally proportional to the number of stations supported. The MADI system is optimized to reduce these overheads by abstraction of directory detail to the station, distribution of the processing requirements amongst connected stations, and providing routing information within the transfer packets. The MADI network is also completely scalable to the immediate requirements, from 2 stations to a maximum of 65,536 stations. The MADI system provides networking facilities to all, at no cost to the cellular service provider. There are no capital outlay requirements, or installation costs for the service provider. The purchaser of the station pays for the MADI layer in the purchased product, all users pay a little for a lot of increased functionality. The MADI system is independent of the Internet, and is thus accessible to everyone who has a compliant PS station, (no internet account is required). However, if an internet capable station is part of the MADI network, then Internet services can be made available to the other connected stations. The MADI system is largely independent of the media interface, since the necessary drivers can be added as necessary. This is particularly useful for the remote connection protocols such as UMTS, GSM, TDMA, and W-CDMA for the PS devices, and the local area networking interfaces such as Bluetooth, and IRDA. The MADI system is designed to interface to, support, and provide mobility management for higher level networking strategies for fixed networks such as JLNI. Transparent access is provided within the MADI network to access only those connected stations that are compatible with the higher level network.

In view of the foregoing it will be evident to a person skilled in the art that various modifications may be made within the spirit and the scope of the invention as hereinafter defined by the appended claims and that the invention is thus not limited to the examples provided. The word "comprising" does not exclude the presence of other elements or steps than those listed in a claim.

Claims

CLAIMS:

1. A dynamically configurable network (20) comprising: a first data station (51j comprising a first service application layer protocol (111) providing a first data service, and a first physical layer protocol (M2); a first wireless protocol station (53) comprising a second service application layer protocol (110), said first wireless protocol station (53) being configured to physically exchange data with said first data station (51) via a first communication link using said first physical layer protocol (M2), and being configured to access said first data service via a peer- to-peer communication using a service access point protocol (91) comprised in said first data station (51) and in said first wireless protocol station (53), in said first data station (51) said service access point protocol (90; 91) being configured to transfer data between said first service application layer protocol (11 1) and said first physical layer protocol (M2), and in said first wireless protocol station (53) said service access point protocol (90; 91) being configured to transfer data between said second service application layer protocol (1 10) and said first physical layer protocol (M2), said first data station (51) and said first wireless protocol station (53) forming a first local area network node (50) in said dynamically configurable network (20).

2. A dynamically configurable network (20) as claimed in Claim 1 , comprising a second data station (52) in said first local area network node (50), said second data station (52) comprising a third service application layer protocol (112) providing a second data service, a second physical layer protocol (M3), and said service access point protocol (90; 91 ; 92), said first wireless access protocol station (53) being configured to physically exchange data with said second data station (52) via a second communication link using said second physical layer protocol (M3), and to access said second data service via a peer-to-peer communication with said second data station (52) using said service access point protocol (90; 91; 92).

3. A dynamically configurable network (20, 25) as claimed in Claim 1, wherein said first wireless protocol station (53) comprises a third physical layer protocol (Ml), said network (20, 25) comprising a second wireless protocol station (63) with a fourth service application layer protocol (1 14), said third physical layer protocol (Ml), and said service access point protocol (90; 94), said second wireless protocol station (63) being comprised in a second local area network node (60), and said first wireless protocol station (53) being configured to physically exchange data with said second wireless protocol station (63) via a third communication link using said third physical layer protocol (Ml), and to access said fourth service application layer protocol (1 14) via a peer-to-peer communication using said service access point protocol (90; 94).

4. A dynamically configurable network (20, 25) as claimed in Claim 3, wherein said second wireless protocol station (63) comprises a fourth physical layer protocol(M2), said network (20, 25) comprising a third data station (61) with a fifth service application layer protocol (1 15) providing a third data service, said fourth physical layer protocol (M2), and said service access point protocol (94; 95), said third data station (61) being comprised in said second local area network node (60), and said second wireless protocol station (63) being configured to physically exchange data via a fourth communication link using said fourth physical layer protocol (M2), and to access said third data service via a peer-to-peer communication using said service access point protocol (94; 95).

5. A dynamically configurable network (20) as claimed in Claim 2, wherein said service access point protocol (90; 91; 92) is configured to directly (A) execute said second data service in said second data station (52) when said second data service is requested from said first data station (51).

6. A dynamically configurable network (20) as claimed in Claim 2, wherein said service access point protocol (90; 91; 92) is configured to indirectly (B) execute a service request (154) from said first data station (51) to perform said second data service (162), said indirect execution being performed by said first wireless protocol station (53).

7. A dynamically configurable network (20) as claimed in Claim 4, wherein said service access protocol (94; 95) is configured to indirectly execute a service request from said first data station (51) to perform said third data service in said third data station (61), said indirect execution being performed through intermediary of said first and second wireless protocol stations (53, 63).

8. A dynamically configurable network as claimed in Claim 1 , wherein data transfer between said first data station (51) and said first wireless protocol station (63) is packet switched.

9. A dynamically configurable network (20) as claimed in Claim 6. wherein data transfer is packet switched, and in said first and second data stations (51, 52; 131, 132) and in said first wireless protocol station (53; 133) said service access protocol (90; 91; 92) uses a respective directory (240, 241, 242) for performing said indirect execution, said directory (240, 241, 242) comprising a node address (221) and a station address (222) of a data station (51, 52) offering a data service to said network (20), and a node address (227) and a station address (22) of a first intermediate station in said network.

10. A dynamically configurable network (20) as claimed in Claim 6, wherein data transfer is packet switched, and a data station (131, 132) said network (20) originating a service request (154) for a data service transmits a packet to a first intermediate station (133), said packet comprising an intermediate destination node address (152) and an intermediate destination station address (153), an intermediate station action command (154), a destination information field (151) for a final destination station (141).

11. A dynamically configurable network (20) as claimed in Claim 10, wherein said destination information field (151) comprises a final destination node address (160), a final destination station address (161). and a final destination action command (162).

12. A dynamically configurable network (20) as claimed in Claim 1 1 , wherein said destination information field (151) comprises a final destination station data field (164), and a final destination data length field (163).

13. A dynamically configurable network (20) as claimed in Claim 10, wherein said packet comprises an intermediate source node address (157) and an intermediate source station address (158), and said destination information field (151) comprises an originating source node address (165) and an originating source station address (166), so as to provide an acknowledgment path for stations between a data service requesting station and a final destination service executing data station.

14. A dynamically configurable network (20) as claimed in Claim 1, wherein data transfer is packet switched, said service access point protocol (90; 91) uses at least one buffer from a buffer pool (280) to form a parent transport packet (150) on the basis of transport information from said first service layer application (1 1 1), and transmits said parent transport packet (150) to a media driver (261). and said service access point protocol (90; 91) uses said at least one buffer to load a received transport packet from said media driver (261), and transfers a destination information in said received transport package to said first service layer application.

15. A dynamically configurable network (20) as claimed in Claim 9, wherein said directory (240, 241, 242) is updated with node address and station address information of passed-through packets when non-existent in a station comprising said directory.

16. A dynamically configurable network (20) as claimed in Claim 9, wherein said directory (240, 241, 242) is updated with node addresses and station address of stations acquired through a station scan by a station comprising said directory (240, 241, 242).

17. A dynamically configurable network (20) as claimed in Claim 16, wherein prior to scanning for stations outside said first local area network node (50; 130), said first wireless protocol station (53; 133) establishes a link to a wireless protocol station (63, 73; 143) outside said first local area network node (50; 130).

18. A wireless protocol station (53) for use in a dynamically configurable network (20) that comprises a data station (51 ) comprising a first service application layer protocol

(111) providing a data service, and a physical layer protocol (M2), said wireless protocol station (111) comprising: a second service application layer protocol (110), said wireless protocol station (53) being configured to physically exchange data with said data station (51) via a communication link using said physical layer protocol (M2), and being configured to access said data service via a peer-to-peer communication using a service access point protocol (90; 91) comprised in said data station (51) and in said wireless protocol station (53), in said wireless protocol station (53) said service access point protocol (90) being configured to transfer data between said second service application layer protocol (1 10) and said physical layer protocol (M2).

19. A wireless protocol station (53) as claimed in Claim 18, wherein data transfer is packet switched, said service access point protocol (90) uses at least one buffer from a buffer pool (280) to form a parent transport packet (150) on the basis of transport information from said first service application layer protocol (111), and transmits said parent transport packet (150) to a media driver (261), and said service access point protocol (91) uses said at least one buffer to load a received transport packet from said media driver (261 ), and transfers a destination information in said received transport package to said first service application layer protocol (111).

20. A data station (51) for use in a dynamically configurable network (20) with a wireless protocol station (53) comprising a first service application layer protocol (110), and a service access point protocol (90), said wireless protocol station (53) being configured to physically exchange data with said data station (51) via a communication link using a physical layer protocol (M2), said data station comprising: a second service application layer protocol (1 11) providing a data service; said physical layer protocol (M2); and said service access point protocol (91), said data station (51) being configured to provide said data service to said wireless protocol station (53) via a peer-to-peer communication using said service access point protocol (91), in said data station (51) said service access point protocol (91) being configured to transfer data between said second service application layer protocol (1 11) and said physical layer protocol (M2).