throbber

`
`very small aperture terminals
`
`Edited by
`JOHN EVERETT
`
`1
`
`Exhibit 1021
`Appl e et al. v. Uniloc
`IPR2019-00510
`
`1
`
`Exhibit 1021
`Apple et al. v. Uniloc
`IPR2019-00510
`
`

`

`Published by: Peter Peregrinus Lid., London, United Kingdom
`
`© 1992: Peter Peregrinus Ltd.
`
`Apartfrom any fair dealing for the purposes of research or private study,
`orcriticism or review, as permitted under the Copyright, Designs and
`Patents Act, 1988, this publication may be reproduced, stored or
`transmitted, in any forms or by any means, only with the prior parmission
`in writing of the pubfishers, or in the case of reprographic reproductionin
`accordance with the termsof licences issued by the Copyright Licensing
`Agency,inquiries conceming reproduction outside those terms should be
`sent to the publishers at the undermentionedaddress:
`
`Peter Peregrinus Ltd.,
`Michael Faraday House,
`Six Hills Way, Stevenage,
`Herts, SGi 2AY, United Kingdom
`
`While the editor and the publishers believe that the information and
`guidance given In this work is correct, all parties must rely upon their own
`skifl and judgment when making use ofit. Neither the editor nor the
`publishers assume anyliability to anyone for any loss or damage caused
`by any error or omission in the work, whether such error or omission is
`the result of negligence or any other cause. Any and all suchliability is
`disciaimed.
`
`The mora! right of the authors to be identified as authors of this work has
`been asserted by them in accordance with the Copyright, Designs and
`Patents Act 1988.
`
`British Library Calaloguing in Publication Data
`
`A GIP catalogue record for this book
`is available from the British Library
`
`ISBN 0 86344 2009
`
`2
`
`

`

`Satellite based messaging systems
`
`351
`
`Fig. 19.1 Network with a single central station
`RT = rural terminal
`
`HUB
`
`19.2.1 System architecture
`
`The first and most important step in the network design is the selection of a
`suitable system architecture [4]. The choice of architecture would depend upon
`the expected pattern of traffic flow in the system and expandability of a given
`architecture.
`There are a numberofpossible architectures for messaging systems but only the
`following alternatives are considered to be important.
`
`In this architecture, all terminals in the network
`19.2.1.1 Fully connected network
`can transmit to all other terminals directly via the satellite channel. The trans-
`ponder capacity can be divided into dedicated channels operating between
`different pairs of terminals or the transponder can be shared byall terminals in
`a multiaccess mode on a single channel at an adequate rate. This architecture is
`attractive from the end user point of view as messages can besent directly to all
`other terminals in the network. However,it is very difficult to implementa fully
`connected networkat the present time with low cost earth stations because of high
`transmit power requirements and large aperture of the antennas.
`
`19.2.1.2 Network with a single hub (star network) This is the most commonarch-
`itecture, depicted m Fig. 19.1, using VSATs because of minimal demandson the
`rural terminals. The central station (or hub) also acts as a post office where
`messages can beleft for users who are currently unable to communicate. It also
`acts as a central database for remote access to information and as a computing
`resource.
`This system is a two hop system;i.e. initially the message is transmitted to the
`
`3
`
`

`

`352
`
`Satellite based messaging systems
`
`a4 _
`
`HUB1
`
`a4 +
`
`mo
`
`HUB 2
`
`w
`
`Fig. 19.2 Network with multiple hubs
`
`hub and from there to the destination rural terminal. In this case the transponder
`capacity can be divided into many channels for communication to and from the
`hub to the rural terminals, or the transponder can be shared byall terminals in
`the network in a multiaccess mode. The channel(s) for communication from hub
`to rural
`terminals can follow different rules than the channel(s) from rural
`terminals to hub.
`
`19.2.1.3 Network with multiple hubs A single hub architecture fails completely if
`the hub becomes unserviceable. Accordingly, the presence of more than one hub,
`indicated in Fig. 19.2, in a network is desirable for establishing a high level of
`system reliability by virtue of in-built system redundancy. In a star network, the
`hub can rapidly become overloaded if demand outgrows the hub capacity. The
`multiple hub architecture can provide a more timely warning of impending
`congestion in the network and the system capacity can be increased by upgrading
`existing hubs or increasing the numberof hubs. This can be a valuable feature
`in large national systems.
`In this case, there are two possible alternatives depending upon the way hubs
`transmit to each other and to rural terminals. The hubs can communicate with
`each other on the same channel(s) as the one used to communicate with rural
`terminals, or the hubs can use separate channels reserved for communication
`between hubs.
`
`In this case, shown in Fig.
`19.2.1.3.1 Single/multiple hubs with asymmetric channel
`19.3,
`the satellite channel
`is asymmetric and different inbound (from rural
`terminals to hub) channels are allocated to groups of users. Each channel in a
`groupis shared by a numberofusers who contendfor it in multiaccess mode. The
`
`
`
`4
`
`

`

`Satellite based messaging systems
`
`353
`
`\
`
`\
`
`‘,
`SN
`
`Sy
`
`\
`
`xMS
`NA
`Iw
`Nv
`ay
`NN —‘
`N
`\\ —\
`‘
`SY
`Vy
`\ \
`pS
`
`RT 4
`
`\ \A
`
`x a
`
`\
`
`yK
`
`RT 3
`
`
`
`HUB G G,
`
`
`
`
`F
`
`f,
`f,
`CHANNELDIVISION
`
`f,
`
`Fig. 19.3
`
`Single hub with asymmetric channel
`
`outbound (from hubto rural terminals) channel is a multiplexed channel and the
`messages transmitted reach all earth stations in the network. Messages are
`displayed only if they are intended for the specific station/user. Either, a preas-
`signed timeslot scheme or addressing information at the beginning of messages
`can be used for distinguishing the destination of a message. The inbound sub-
`channels are relatively low capacity, typically less than 64 kbit/s, whereas the
`outbound channelis high capacity, typically 512 kbit/s.
`This configuration gives full connectivity in two hops as every terminal can
`transmit to every other terminal on the network via hub(s). The advantages are
`the capability to support a very large numberof users and incremental network
`expansion by adding more subchannels with increase in demand. This architec-
`ture takes full advantage of the high transmit power of a hub to support a high
`speed outbound channel compared with the inbound channel whichis easily
`provided by rural terminals.
`
`Yn this architecture, depicted in
`19.2.1.3.2 Multiple hubs with symmetric channels
`Fig. 19.4, the rural terminals are able to transmit to a limited numberof hubs;
`either one or two. The hubs transmit among themselves on separate channel(s)
`reserved for the purpose. The messages from one rural terminal to another take
`three hops in the worst case.
`
`5
`
`

`

`354
`
`Satellite based messaging systems
`
`
`
`
`
`Fig. 19.4 Multiple hub with symmetric channels
`
`CHANNELDIVISION
`
`The transponderis divided into many channels and a groupofrural terminals
`and a hub share one channel. The membersof a group use a suitable multiaccess
`protocol to acquire the allocated channel. If the hub being used byagroupfails,
`the whole group may not be able to communicateatall: hence, an alternative
`arrangement must be provided. Either, a shared back-up hub can be provided
`for all groups or the rural terminals can be programmedto switch over to an
`adjacent groupin case offailure of the hub.
`
`19.2.2 Comparison of architectures
`It is highly desirable to have multiple hubs in the network because:
`e A multiple hub architectureis highly flexible and allowsfor further expansion
`of the network: hubs can be added to the network when demand increases
`e The architecture is fail-safe as the system does not collapse completely even
`if a few hubsfail simultaneously
`e Manypotential applications of the network indicate the need for a multiple
`hub architecture as discussed below.
`
`The choice of an architecture should be made after considering overall cost,
`reliability and applications to be satisfied by the system. For example, most
`
`6
`
`

`

`Satellite based messaging systems
`
`355
`
`messaging networks can also provide access to information (a query to a data-
`base), transmission of vital data, or remote access to computing resources.In all
`of these applications hierarchical structure is necessary as social, political and
`business systemsare usually organised for flow of information from rural locations
`to a central hub. The system would have a large numberofusers spread through-
`out the country and hence the traffic pattern is a key factor in arriving at a
`suitable system architecture. The existing telecommunication infrastructure in-
`dicates that most of the traffic flow is from small towns andcities to the met-
`ropolitan cities. Also, a large amountoftraffic flow is amongthese cities. This
`implies that multiple hubs with full connectivity provide an attractive architec-
`ture matched to user needs and system objectives.
`An important advantage of dividing a channelinto subchannelsis that groups
`of users with commoninterests can share a subchannel withoutinterfering with,
`or getting interfered by, other groups/users. They can share commoninterest
`data-bases and remotely located resources. Built-in security and protection mech-
`anisms exist so others outside the group can be prevented from accessing secret
`or sensitive information. The grouping can be implemented based upon geo-
`graphical criteria or upon any other commoninterest; e.g. a regional grouping
`(western, eastern, central etc) is a good choice as the majority of messages can be
`expected to flow within a region. Banks,
`libraries, railways, health services,
`community and educational institutions could form separate groups. Careful
`study of current
`traffic patterns and future needs is required to decide on
`groupingcriteria. The architecture suggested in Fig, 19.4 is flexible and can easily
`be modified as requirements change over a period oftime.
`In a system which uses hubstation(s), the traffic to and from these hub(s) will
`be highly asymmetrical. Messages originating from rural terminals are transmit-
`ted to a hub which retransmits them to the appropriate destination and
`sometimes responds to queries from rural terminals. Thus, there is almost con-
`tinuoustraffic from hub to rural terminals. On the other hand, incomingtraffic
`to the hubis bursty in nature. This imbalance betweentraffic in and out of hub(s)
`makes it highly desirable to employ different types of channel access protocols for
`inbound and outbound channels. A multiaccess protocol for
`the incoming
`channel, which is characterised by bursty traffic from a large numberofstations,
`and simple time division multiplexing for the outgoing channel, which has a
`continuous transmission to a large numberofstations, would appearto represent
`an optimum choice. This imbalance in traffic flow will be reflected in the
`difference in transmission rates between the inbound and outbound channels.
`
`19.3 Multiaccess techniques
`
`These are broadly divided into polling, reservation, demand assignment and
`random access schemes. Each has its own advantages and disadvantages. The
`suitability of each of these schemes, especially to messaging applications, will now
`be considered.
`the fact that messaging
`In evaluating the different multiaccess techniques,
`systems need not operate in an on-line real-time mode should be taken into
`account:
`this results in a relaxation of the maximum delay tolerable by the
`network. Even an access time of a few minutes will be considered acceptable in
`
`7
`
`

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket