1. Difference between BO and DTO
A business object contains both data and behavior, and it can be considered a full-fledged active object participating in the domain logic. A data-transfer object is a sort of value object—namely, a mere container of data with no attached behavior. The data stored in an instance of a BO is typically copied into a DTO for serialization purposes. The DTO has no logical behavior except for get accessors and set mutators. There might be multiple DTOs for each domain entity class in the model. Why multiple DTOs?
A DTO is not simply a behaviorless copy of a domain object. It is, instead, an object that represents a subset of a particular domain object as you would use it in a particular context. For example, in one method you might need a Customer DTO with only the company name and ID; elsewhere, you might need another one with the ID, company name, country, and contact information. Generally, however, a domain object is a graph of objects—for example, the Customer includes orders, which include order details, and so forth. A DTO indicates any needed projection of this aggregate.
2. Layer vs Tier
A layer is merely a way of organizing your code. When you mention the presentation layer, for instance, you are referring to the functions that you expect from the application's front end. You are not referring to a particular client platform or technology. Or, at least, you shouldn't be.
A tier, on the other hand, refers to where the code runs. For this reason, a tier is often referred to as a physical tier, or perhaps a physical layer. More specifically, a tier is the place where architects make logical layers run.